LAST MODIFIED: 2013/07/28 17:20:42 UTC
不定期更新の日記です。ディスクスペースの関係上、 あまりに古くなったものは順次消していきます。 この日記の更新は、今野さんの *BSD Diary Links から取得することが可能です。
2年ぶりくらいに更新。そろそろ手書きマークアップは止めようかと思いつつ。
ZFS で構成した 10TB クラスのストレージ運用を開始してから数年経ちました。 いろいろな落し穴にはまりつつ、現在は FreeBSD 9.1 で無難な運用ができるようになっています。半年以上トラブルなしです。
鉄則をいくつか。 現在は頑張ってチューニングしなくともかなり安定して動きます。
64 ビット版の OS (amd64 など) を使い、メモリは 8GB 以上載せましょう。
dedup は使わないこと。
連続書き込み性能が低く出るワークロードの場合は、 vfs.zfs.vdev.min_pending, vfs.zfs.vdev.max_pending, vfs.zfs.txg.timeout を小さく設定しましょう。 ただし書込集約が減るので、フラグメンテーション発生の頻度は上がります。
ARC はメタデータに割り当てる分量を増やすのがおすすめです (vfs.zfs.arc_meta_limit を増やす)。 これは UFS と比較すると、メタデータの処理負荷が高めで、 全体的な速度の足枷となることが多いからです。 データのキャッシュがたくさんほしい場合は、 SSD を L2ARC (cache デバイス) として追加しましょう。
キャッシュの利用効率は、sysutils/zfs-stats にある zfs-mon コマンド（top 風にキャッシュヒット率を表示する）を使うと簡単に調べることができます。 このコマンドを -a オプション付きで数時間実行し続けて、数字を確認しましょう。 ARC のヒット率は、普通の設定で 90% を超えているはずです。また、その時の ARC demand metadata のヒット率も 90% を超えていることが望ましいです。 この値が極端に小さい場合、そのマシンのワークロードに対して メタデータ用の ARC が足りないということなので、 vfs.zfs.arc_meta_limit を増やしてあげましょう。
そして、もうひとつ。ARC を手動で設定 (vfs.zfs.arc_min と vfs.zfs.arc_max) した時には、 増やしすぎていないかをチェックするのを忘れないでください。
このチェックは、当該マシンの ZFS 以外のメモリ負荷に依存しますので、 なかなか調べるのが難しいところです。たとえば NFS サーバとして動いているマシンで ARC を物理メモリぎりぎりまで設定した場合、 クライアントからのアクセスが集中しているタイミングでメモリが足りなくなることが良くあります。 FreeBSD は swap in/out を使ってメモリ不足を回避しますが、性能がかなり低下して見えることと、 かなりまれな確率ですが、swap in/out と ZFS のメモリ要求がデッドロックするパターンがあります。
これは、top や vmstat でメモリ使用量を監視する、という方法で捕捉するのは困難です。 確実なのは、swap in/out の頻度を監視する方法になります。
具体的には、vm.stats.vm.v_swappgsout と vm.stats.vm.v_swappgsin を監視します。 これは swap in/out したページ数を表しています。 10 秒単位で値を保存するスクリプトをつくって 1-2 日稼働させた状態のデータをとり、 1 秒間あたりの処理ページ数に換算してみます。平均して 1 を切っているようなら、特に心配は要りません。 さらに ARC を増やしても大丈夫でしょう。
これが平均しても 10 や 100 と出てきた場合は、ARC のとりすぎです。 値が小さくなるまで、ARC を減らしてください。毎秒 1000 ページ (実に 4MB/s) の swap in/out が発生していても、 FreeBSD は見かけ上安定して動作できるだけの能力を持っていますが、 1000 を超える場合はデッドロックに陥る危険性が高く、安定運用が望めません。（し、swap 処理の負荷が高くて ZFS の性能にも影響が出ます）
1 年ほどまえに構築したシステムでは、これに気づかずに大きめに ARC を設定していた結果、 10-20 日に一回くらいのペースでシステムが止まる、という現象に悩まされました。
LAST MODIFIED: 2013/07/28 17:20:42 UTC