非常に大きなzpoolであっても、ZFSは本当にすべてのvdevにまたがっていますか？
すべてのvdevがプールの寿命の初めに追加されると仮定して、ZFSがすべてのトップレベルvdevにわたってzpool内のデータをストライプ化することを読みました。私が読んだすべてのものは、これを良いことだと考えているようです。しかし、多くのディスクを使用した展開の場合は、マルチユーザー（またはマルチプロセス）環境でこれらすべてのディスクの全体的なパフォーマンスが向上するわけではないように思われます。
たとえば、96個のディスクがあり、それぞれ8個のディスクからなる12個のvdevを作成するために使用し、それらすべてをzpoolに追加するとします。それから私はそれをユーザーに緩め、彼らはそれをあらゆる種類の狂気で満たす。一部のファイルは数十ギガバイトであり、その他のファイルは小さなユーザーアプリケーション構成ファイルなどです。
後で、ユーザーAはいくつかの数ギガバイトのファイルをコピーしたいと考えています。彼女はrsyncなどを開始し、12個のストライプvdevからの基礎となるシーケンシャル読み取りから驚異的なパフォーマンスを体験します。しかし、ユーザーBは、一度にかなり大きなデータのチャンクを要求する別のアプリケーションを起動します。現在、ドライブヘッドはユーザーBを処理するためにユーザーAのrsyncから絶えず引き離されており、各アプリケーションは個別に比較的シーケンシャルですが、96個のディスクはすべて両方のユーザーの要求に関与しており、ランダムI /とより一貫したシークパターンとパフォーマンスを確認します。 O。
この8ディスク構成の12vdevでは、各vdevのパフォーマンスは8ディスクに相当するため、他のvdevにストライピングを追加しなくても、シーケンシャルI/Oは非常に優れていると思います。 ZFSが別のvdevに移動する前に、1つのvdevに多くのギガバイトを配置する方が良いのではないでしょうか。 （私の実験では、約500kのストライプが発生しています。）このようにすると、ユーザーAの読み取りはユーザーBの読み取りと同じディスクを使用する可能性が1/12になり、どちらもシーケンシャルI /と一貫したパフォーマンスが得られます。ほとんどの場合。
この構成/ワークロードでZFSから良好なパフォーマンスを得る方法はありますか？
ZFSは常にすべてにストライプしますvdevsファイルに必要なブロック数によって異なりますが、小さなファイルは多くの場合、単一のブロックに収まるため、で構成されたデータセットに属していない限り、単一のvdevに到達します。 copies = 2またはcopies =。
いいえ、個別のプールを作成せずに変更したり分割したりすることはできません。
このようなストライプ設定よりもパフォーマンスを向上させるために、ZFSは独自のIOスケジューラーをZIOコンポーネントに含めます（Linuxではdeadlineまたはnoop）である理由ですスケジューラーをお勧めします）。
このようなワークロードを改善する別のレイヤーは[〜＃〜] arc [〜＃〜]で、これには特にプリフェッチキャッシュが含まれます。個別の高速デバイスでL2ARCを使用してARCを高速化できます。同期書き込みに相当するのは、SLOG（専用ZILデバイス）です。