ZFSはキャッシュのヒット率が超重要この記事には技術的裏付けがない、個人の感想、雑感、推測がふんだんに含まれています。ご利用の際は用法・用量を守り正しくお使いください。知人のNAS4Freeなファイルサーバが重い問題、Sambaが原因で一件落着かと思いきや解決してなかった。(こっちはこっちで別の問題が発生してたりするので別途書く予定。その他諸々を継続的にモニタリングしてみると、どーにもディスクアクセスがボトルネックになっている事があるようで...。ファイルサーバのターミナルで直接cpしても、全然速度が上がらないのだ。2ペア×3セットからなるRAID10である。十数MB/sは出るだろうと思ってたが、実際には1MB/s以下になることさえある。iostatしてみた結果がこちら。2.39M読み込み操作数(operations)と読み込み量(bandwidth)の割に、書き込み量が著しく少ない。コピーと並行してSambaへ断続的なアクセスがあるってことを差し引いても全然スループットが出てない。書き込み量とネットワークに出ていく量を合わせても全然読み込み量に足らん罠。大量の読み込みoperationsが走ってても、いい感じに処理できてる時は↓こんな感じで順当にbandwidthが上がる。CIFSによるリクエスト分がそのまま処理されてネットワークに流れていっている。6.61Mrsyncでディスク内コピーを行うと更に悲惨で、びっくりするほど速度が出ない。sendし、そいつとrsyncで同期した方が早いっていうね...。すわ、断片化か!?と思ったけど、プールは半分以上空いてるしちょっと考えにくい。あれこれ考えてるうちに、ZFSはキャッシュのヒット率が重要って事を思い出した。1フォルダに大量の細かなファイルがあるって事は、その分メタデータ処理が重いと考えられる。すれば、メタデータを使いまくってそうなrsyncで速度が出ないってのも説明が付く.........気がしなくもない。zfs-statsを入れてキャッシュのヒット率を見てみたら、なんと2割を切ってるじゃないの。operationsの割にbandwidthが上がらなかったのかしら...?とりあえずarc関連のカーネル変数を調整したところ、いい感じでキャッシュヒットするようになった。問題のプール内のディレクトリ間でrsyncした時の結果が↓これ。iostatは1秒毎、vfs.zfs.txg.timeout=5である)。Tags:FreeBSDPCZFSCommentsNameE-MailWebsite人間の証明として、ボックス内の全ての文字を入力してください。Decomoソースの表示以前のリビジョンメディアマネージャー文書の先頭へ。