ZFSパフォーマンス：プールまたはファイルシステムに空き領域を保持する必要がありますか？

ZFSのパフォーマンスは空き領域の量に大きく依存することを知っています。

プールのパフォーマンスを維持するために、プールの使用率を80％未満に抑えます。現在、プールが非常にいっぱいで、ビジーなメールサーバーなどでファイルシステムが頻繁に更新されると、プールのパフォーマンスが低下する可能性があります。プールがいっぱいになると、パフォーマンスが低下する可能性がありますが、他の問題は発生しません。[...]静的コンテンツのほとんどが95〜96％の範囲であっても、書き込み、読み取り、再同期のパフォーマンスが低下する可能性があることに注意してください。ZFS_Best_Practices_Guide、solarisinternals.com（archive.org）

ここで、ZFSファイルシステムをホストする10Tのraidz2プールがあるとしますvolume。次に、子ファイルシステムを作成し、volume/test5Tの予約を与えます。

次に、NFSごとに両方のファイルシステムをいくつかのホストにマウントし、いくつかの作業を実行します。volume残りの5Tはに予約されているため、5T を超える書き込みはできないことを理解していvolume/testます。

私の最初の質問は、volumeマウントポイントを〜5Tで満たした場合、パフォーマンスがどのように低下​​するかです。ZFSのコピーオンライトやその他のメタデータのためにそのファイルシステムに空きスペースがないので、ドロップしますか？または、ZFSは予約されたスペース内の空きスペースを使用できるため、同じままvolume/testですか？

今2番目の質問。次のように設定を変更すると、違いが生じますか？volume現在、2つのファイルシステムがvolume/test1ありvolume/test2ます。両方にそれぞれ3T予約が割り当てられます（クォータはありません）。今、私は7Tをに書きtest1ます。両方のファイルシステムのパフォーマンスは同じですか、それともファイルシステムごとに異なりますか？落ちますか、それとも変わりませんか？

ありがとう！

はい。プールに空きスペースを確保する必要があります。主にコピーオンライトアクションとスナップショット用です。使用率が約85％になるとパフォーマンスが低下します。高くすることもできますが、明確な影響があります。

予約を台無しにしないでください。特にNFSで。それは必要はありません。たぶん、zvolではなく、NFSでは。

しかし、混乱は見られません。10Tを使用している場合、その85％以上を使用しないでください。使用量を制限するクォータを使用して、共有のサイズを適切に設定します。または、クォータを使用せず、プール全体の使用状況を監視します。

パフォーマンスが低下するのは、zpoolが非常にいっぱいになるか、非常に断片化される場合です。この理由は、ZFSで使用されるフリーブロック検出のメカニズムです。NTFSやext3などの他のファイルシステムとは異なり、使用中のブロックと空きブロックを示すブロックビットマップはありません。代わりに、ZFSはzvolを「メタバス」と呼ばれる（通常200）より大きな領域に分割し、各メタスラブに空きブロック情報（スペースマップ）のAVLツリー¹を格納します。バランスの取れたAVLツリーにより、要求のサイズに適合するブロックを効率的に検索できます。

このメカニズムは規模の理由から選択されていますが、残念ながら、高レベルのフラグメンテーションやスペース使用率が発生した場合に大きな痛みになることも判明しました。すべてのメタスラブが大量のデータを運ぶとすぐに、プールが空の場合の少数の大きな領域ではなく、多数の空きブロックの小さな領域が得られます。ZFSは2 MBのスペースを割り当てる必要がある場合、すべてのメタスラブのスペースマップの読み取りと評価を開始して、適切なブロックを見つけるか、2 MBをより小さなブロックに分割する方法を見つけます。これにはもちろん時間がかかります。さらに悪いことに、ZFSは実際にすべてのスペースマップを物理ディスクから読み取るため、I / O操作に多大なコストがかかるという事実です。以下のための任意のあなたの書き込みの。

パフォーマンスの低下が著しい場合があります。きれいな写真をお望みなら、Delphixのブログ投稿をご覧ください。いくつかの数字が（単純化されているがまだ有効な）zfsプールから削除されています。グラフの1つを恥知らずに盗んでいます-このグラフの青、赤、黄、緑の線を見てください。時間とともに断片化するKB / s：

これに対する迅速で汚い修正は、従来、メタスラブデバッグモードでした（echo metaslab_debug/W1 | mdb -kw実行時に設定を即座に変更するための問題です）。この場合、すべてのスペースマップはOS RAMに保持され、各書き込み操作での過度で高価なI / Oの要件がなくなります。最終的に、これはまた、特に大きなプールの場合、より多くのメモリが必要であることを意味します。したがって、それは一種のストレージホーストレードのRAMです。10 TBのプールではおそらく2〜4 GBのメモリ²が必要になりますが、手間をかけずに使用率の95％に増やすことができます。

¹少し複雑です。興味がある場合は、詳細についてはスペースマップに関するBonwickの投稿を参照してください。

²メモリの上限を計算する方法が必要な場合は、各メタスラブzdb -mm <pool>でsegments現在使用中の数を取得するために使用し、それを2で割って最悪のシナリオをモデル化します（占有された各セグメントの後に空きセグメントが続きます） ）、これにAVLノードのレコードサイズ（2つのメモリポインターと値、zfsの128ビットの性質と64ビットアドレッシングが合計32バイトになると仮定しますが、一般的には理由）。

zdb -mm tank | awk '/segments/ {s+=$2}END {s*=32/2; printf("Space map size sum = %d\n",s)}'

参照：基本的なアウトラインは、zfs-discussメーリングリストのMarkus Koveroによるこの投稿に含まれていますが、私が彼の計算で間違いを犯したと思います。