ZFS ARCのチューニング：上限、制限、および測定すべき項目

ZFSはデフォルトで、システムRAMの約半分を静かに読み取りキャッシュとして使用します。不適切なサーバー環境では、これがスワップの発生、OOMによるプロセス強制終了、あるいはデータベースがファイルシステムとメモリを奪い合う事態を招く可能性があります。ZFSのARCチューニングとは、ARCが実際に保持することを許可するRAMの量を決定し、その制限を設定するために何を犠牲にするかを決めることです。 この記事では、ARCのメモリ使用方法、設定を変更する前に測定すべき項目、変更する価値のある数少ない調整パラメータ、およびファイルサーバー、ハイパーバイザー、データベース、バックアップ先における適切な初期設定値について解説します。ZFSのスナップショット機能については、ZFSスナップショットに関するガイドをご覧ください。

調整を行う前にARCを測定してください

通常の繁忙期のベースライン数値が得られるまでは、調整可能なパラメータを一切変更しないでください。閑散期のスナップショットでは、誤った方向へと導かれてしまいます。通常、ARCの挙動が注目されるのは、毎晩のバックアップ、週次レポート、バッチジョブの処理時であるため、数日にわたってデータを収集してください。

必要な機能のほとんどは、以下の3つのツールでカバーできます：

• arcstat 1 ヒットおよびミスカウンター、デマンドとプリフェッチの活動状況、現在のARCサイズをリアルタイムでスクロール表示します。負荷テストやバックアップウィンドウ中に使用してください。
• arc_summary 単一のスナップショットを出力します：ARCサイズとターゲット、MFU/MRUの内訳、メタデータ比率、およびアクティブな調整可能なパラメータ。 arc_summary -s arc を実行すると、ARCセクションのみが表示されます。
• 生のカウンタは /proc/spl/kstat/zfs/arcstats にあり、Linuxでは kstat.zfs.misc および vfs.zfs FreeBSDのsysctlツリー内に存在します。フォーマット済みの出力を解析するのではなく、モニタリングからこれらを取得してください。

変更を行う前に記録しておくべきカウンターは以下の通りです：

ここで多くの人が誤解しがちな点が2つあります。「空きメモリ」ではなく「利用可能メモリ」を監視してください。Linuxは、空きRAMが少ない状態でも安定した状態として報告しますが、それ自体は問題ではありません。 重要な指標は、利用可能メモリがゼロに近い状態であり、かつスワップ活動が持続している場合です（その理由については『Linuxメモリ管理入門』で解説されています）。また、ヒット率は目標値としてではなく、傾向として捉えてください。スワップが発生しているシステムで99％のヒット率を達成しても、それはチューニングの成功ではなく、失敗です。

重要な4つのARC調整項目

本番環境のチューニングのほとんどは、4つの設定に集約されます。設定は、ベースラインで実際に測定した負荷に合わせて調整してください。スワップアクティビティは zfs_arc_maxに設定してください。ホットキャッシュを繰り返し消去し続けるチャーンの回収は、 zfs_arc_minに設定します。ディレクトリ探索が遅い場合は、メタデータ制限に原因があります。

目に見える負荷に対処できる最小限の変更から始めましょう。 zfs_arc_max適切な上限値はワークロードによって異なります（次のセクションで説明します）。 zfs_arc_minについては、もし上限値が必要であれば、 zfs_arc_max を基準とするのが妥当な出発点となります（設定が必要な場合に限ります）。メタデータについては、最近の OpenZFS のデフォルト設定では、すでに zfs_arc_meta_limit_percent、これはほとんどのワークロードにとって十分な値です。この設定を変更するのは、 arcstat.

LinuxおよびFreeBSDでの変更の適用

Linux では、sysfs パラメータファイルに書き込むことで、実行時に変更をテストできます。再起動は不要です：

echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max

これにより zfs_arc_max を即座に16 GiBに設定します。再起動後も変更を反映させるには、これを /etc/modprobe.d/zfs.conf:

options zfs zfs_arc_max=17179869184

FreeBSDでは、実行時の変更には sysctl:

sysctl vfs.zfs.arc_max=17179869184

同じ値を /boot/loader.conf:

vfs.zfs.arc_max="17179869184"

設定の変更は一度に1つずつ、総RAMの約10%程度の小さなステップで行ってください。問題が発生する期間を注意深く観察してください。スワップがゼロのままであり、レイテンシが安定している場合にのみ、その変更を維持してください。実行時テストに合格した後にのみ、変更を永続化してください。

ワークロードに応じたARCのチューニング

総RAM容量から検討を始めるのは誤りです。ARCのサイジングは、そのサーバー上のワークロード構成に基づいて行う必要があります。

VMホストはゲストとメモリを共有する必要があるため、30%～40%の上限が安全なデフォルト設定であり、50%はほとんどのビルド環境においてすでに高すぎる。PostgreSQLやMySQLのようなデータベースは独自のバッファキャッシュを管理するため、まずエンジン用にメモリを確保し、残りをARCに割り当てる。 バックアップ先には次のような利点がある primarycache=metadata 。読み込まれたデータが再度必要になることはめったになく、毎晩のバックアップがプール全体を走査し、その過程でキャッシュの残りをフラッシュしてしまうような事態は避けたいからです。あらゆるワークロードにおいて、ARCが zfs_arc_max 状態にある際のスワップ活動は、上限が高すぎることを意味します。このルールは変わりません。

問題の診断と停止のタイミングの見極め

ARCのサイズが小さすぎると、システムに空きRAMがあるにもかかわらず、読み取りIOPSが高くなり、デマンドヒット率が低下し、ディレクトリの閲覧が遅くなるといった現象が見られます。一方、ARCのサイズが大きすぎる場合は、その兆候がそれほど明確ではありません。ヒット率は問題ないように見えますが、システムはスワップを開始し、負荷平均が上昇し、カーネルがオンデマンドでARCページを回収している間、プロセスが D 状態になり、最悪の場合、OOMキラーが犠牲となるプロセスの選定を開始します。キャッシュは正常に見えますが、サーバーのパフォーマンスは著しく低下します。

メタデータの負荷は、 demand_metadata_bytes が demand_data_bytes よりも arc_summary。これは、メタデータがデータとスペースを奪い合っている状態であり、メタデータの割合制限を引き上げる価値があります。

確認すべき最初の設定と、実際に見られる状況を照らし合わせてください：

L2ARCは無料ではありません。L2ARCエントリのインデックスはプライマリARC内に存在し、そのオーバーヘッドがARC総容量の約3分の1を超えると、セカンダリキャッシュはメリットよりもデメリットの方が大きくなります。 L2ARCを活用するのは、ワーキングセットがRAM容量を上回るものの、高速なNVMeデバイスに収まる場合に限るべきであり、かつプライマリARCのヒット率がすでに良好な状態にある場合のみとする。

チューニングを終了する適切なタイミングは、レイテンシが横ばいになり、当初の問題を引き起こしたのと同じ高負荷時間帯を通じてスワップがゼロのままであり、それ以上の変更によって改善が見込めなくなったときです。サーバーがスワップを行っている場合、高いヒット率は意味をなしません。その時点を過ぎたら設定の調整を中止し、同じワークロード下で同じ問題が再発した場合にのみ、設定を見直してください。

VMやデータベースとメモリを奪い合うことなく、ZFSを適切に実行できるだけのRAMの余裕があるサーバーが必要な場合（実際にどれだけのRAMが必要かは、まず一読する価値があります）、FDCの専用サーバーをご検討ください。