サーバーと仮想マシン

vm.vfs_cache_pressure の解説 – Linux ファイルシステムのキャッシュを最大限に活用する

カーネルパラメータ vm.vfs_cache_pressure VFSキャッシュとページキャッシュの重み付けを調整し、実際の負荷プロファイルにおいてどの設定がパフォーマンス向上につながるかを検証します。明確な手順に従ってこの設定を調整し、その効果を測定することで、 ファイルシステムキャッシュ 最適。.

中心点

すぐに始められるように、チューニングに関する最も重要なポイントをまとめておきます。 VFSキャッシュ これらを総合的に考慮します。これにより、値を選択する際に、メタデータ検索、I/O負荷、およびRAMへの負荷への影響を常に念頭に置くことができます。これらのポイントは、一般的なサーバーの役割を確実かつ再現性高く最適化するのに役立ちます。.

作用原理: カーネルがページキャッシュと比較して、Dentries/Inodesをどの程度積極的に解放するかを制御します。.
デフォルト設定: 100は、特定の要素を優先することなく、バランスよく調整された状態を意味します。.
低い数値: 50～80に設定すると、メタデータがRAMに長く保持され、ファイルの検索が高速化されます。.
高い数値: 120～200に設定すると、VFSキャッシュの解放が速くなり、プロセス用に空き領域が確保されます。.
練習: 段階的に変更し、測定し、記録する――その上で、さらに調整を進める。.

私は、以下の原則を一貫して適用し、 キャッシュ・ヒット率 と空きRAMを確認します。その後、vm.vfs_cache_pressure を少しずつ調整し、負荷のピークを観察して、必要に応じて修正します。こうすることで、予期せぬメモリ不足を起こすことなく、安定した応答時間を実現しています。.

vm.vfs_cache_pressure とは何ですか？

このパラメータは、カーネルが VFSキャッシュ 他のストレージと比較して、RAMが不足するとすぐに空き領域を確保します。VFSキャッシュには、デントリやiノード、つまりディレクトリエントリやファイルメタデータが格納され、ファイルの検索速度が著しく向上します。値を100に設定すると、VFSキャッシュとページキャッシュが同等に扱われますが、値を下げると、メタデータを優先的にRAMに保持するようになります。値を大きくすると、カーネルはVFSエントリをより早く破棄し、メモリを迅速に解放するようになります。私はこの設定を意図的に活用し、プロセスを追い出すことなく、Web、ファイル、CMSのワークロードにおけるメタデータのヒット率を高く保っています。このようにして、以下のバランスを調整しています。 ルックアップ速度 および空きメモリに非常に直接的に影響します。.

VFSキャッシュは具体的にどのように機能するのでしょうか？

仮想ファイルシステムは、ext4、XFS、Btrfsなどのファイルシステムを統合する共通レイヤーを形成し、以下を保存します デントリーズ また、RAM内にiノードを保持することで、ディレクトリのスキャンや繰り返し行われるアクセスを高速に保ちます。一方、ページキャッシュは実際のファイルブロックを保持します。両キャッシュは互いに補完し合いますが、負荷がかかるとメモリの奪い合いになります。小さなファイルが多く、頻繁に繰り返しアクセスされるほど、アプリケーションはメタデータのヒット率が高いことによる恩恵を大きく受けます。まさにここで vm.vfs_cache_pressure が効果を発揮します。私は、Linux がこのメタデータを保持するか、それとも速やかに追い出すかを制御します。ページキャッシュに関するより詳細な側面については、補足としてコンパクトなページキャッシュ・パフォーマンス・ブースター VFSやページキャッシュを文脈に沿って評価できるよう、背景知識として理解しておく。.

標準値および代表的な値の範囲

ほとんどのシステムでは、この値は 100 これにより、初期テストのためのバランスの取れた基盤が整います。この値を下げると、メタデータが優先され、高速な検索が安定します。これは特に、多数の小さなファイルがある場合に効果を発揮します。この値を上げると、LinuxはVFSエントリをより速く解放し、アプリケーションやページキャッシュのためにより多くのバッファを確保します。 0 や 500 を超えるような極端な値については、動作に大きな影響を与えたり、予期せぬ副作用を引き起こす可能性があるため、非常に慎重に取り扱っています。日常的には 100 から始め、20～40 ポイントずつ段階的に調整しながら、その効果を測定しています。 IOレイテンシ および応答時間。.

価値	意味	使用時期	リスク／注意事項
< 100（例：50～80）	VFSキャッシュはRAMに長く留まる	多数の小さなファイル、頻繁な検索	RAMへのバインディングを増やすメタデータ
100	バランスの取れた調整	測定のための確かな初期値	グッドベースライン-値
> 100（例：120～200）	VFSキャッシュの解放がより積極的に行われるようになった	RAMが不足している場合、独自のキャッシュを持つデータベース	発生しうるルックアップの遅延
極端（0、> 500）	重大な変化	特殊なケース、簡単にテストする	安定性への脅威とパフォーマンス

この枠組みを使えば、行き当たりばったりになることなく、どの方向が適切かを素早く見極めることができます。急激な変化は避け、変更点の一つひとつを詳細に記録します。そうすることで、これまでの経緯が常に明確になり、以前の測定ポイントとの比較も正確に保つことができます。.

ストレージのクリーンアップにおける役割

負荷がかかると、カーネルはRAMを解放しなければならず、まさにこの時点で、vm.vfs_cache_pressure が以下の間の重み付けを定義します。 VFSキャッシュ, 、ページキャッシュ、およびプロセスメモリ。値を低く設定すると、ディレクトリエントリやiノードエントリがメモリに長く保持されるため、ディレクトリ参照や繰り返しのファイルオープンが高速に処理されます。値を高く設定すると、メモリの解放が早まり、プロセスやページキャッシュのためにより多くの領域が確保されるため、RAMが不足している場合に役立ちます。メタデータキャッシュが空になりすぎるとファイル検索が遅くなるため、私は特にI/Oレイテンシに注目しています。ページキャッシュの解放戦略との連携において、この知見は私に以下の情報を提供してくれます。ページキャッシュの追い出し実践的な知見が得られ、事実に基づいて意思決定を行うことができる。.

測定方法：VFSキャッシュの可視化

変更する前に、それを目に見えるようにします。, どこメモリが搭載されており、何押しやられてしまう。そうすることで、メタデータが本当にボトルネックなのか、それともページキャッシュやプロセス、あるいはダーティページが主な要因なのかを見極めることができる。.

/proc/meminfo: InodeCache、Cached、Buffers、SReclaimable、SUnreclaim を確認し、その割合と回収可能性を評価します。.
スラブトップ: スラブ、特に dentry、inode_cache、ext4_inode_cache、xfs_inode のリアルタイム表示。これにより、デントリーや iノードの容量が増減しているかどうかを確認できます。.
IOパス: vmstat/iostat を使って、読み取りレイテンシや、ルックアップ時にディスクアクセスが増加していないかを監視しています。.

# 概要
grep -E 'InodeCache|SReclaimable|SUnreclaim|Cached|Buffers' /proc/meminfo

# スラブの分布（サイズ順）
sudo slabtop -s c

# dentry/inode 類似のスラブのみを抽出
grep -Ei 'dentry|inode' /proc/slabinfo | sort -k3 -nr | head

# 1秒ごとのI/Oおよびメモリの傾向
vmstat 1
iostat -x 1

この解釈は明確だと私は考えています。SReclaimableがdentry/inodeスラブとともに増加し、同時にI/Oレイテンシも上昇する場合ない, これはメタデータキャッシュが有効に機能していることを示しています。これらの値が頻繁にゼロになり、ディレクトリアクセス時のレイテンシが急上昇する場合は、vm.vfs_cache_pressure の設定が過度に積極的である可能性があります。.

実践：現在の値の読み取りと変更

コマンドライン上では、数秒で、しかも リスタート. 実際の値を読み取り、テスト値をまずは一時的に書き込むことで、テストウィンドウでの戻りを即座に反映できるようにしています。本番環境での調整を行う際は、/etc/sysctl.conf または /etc/sysctl.d/ 内のファイルに設定を記述し、再読み込みを行った上で、その変更内容をドキュメントに記録します。効果を明確に把握できるよう、各レベルをアイドル状態だけでなく、現実的な負荷下でテストします。これにより、正確な「変更前・変更後」の比較を確保し、測定可能な指標に基づいて変更を評価します。.

# 現在の値を確認する
cat /proc/sys/vm/vfs_cache_pressure
# または
sysctl vm.vfs_cache_pressure

# 一時的にテスト（再起動まで）
sudo sysctl -w vm.vfs_cache_pressure=60
# 別の方法
echo 60 | sudo tee /proc/sys/vm/vfs_cache_pressure

# 永続的に設定
echo "vm.vfs_cache_pressure = 60" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Linuxのキャッシュチューニング：有効なシナリオ

静的アセットやファイルストレージが多く、あるいは独自のバッファを持つアプリケーションが存在するホスティング・プラットフォームでは、的を絞った 重み付け VFSキャッシュの値。小さなファイルが多数存在するWebサーバーでは、SSD/HDDへのルックアップ頻度が減るため、この値を低く設定すると大きなメリットがあります。ファイルサイズが混在するファイルサーバーでは、十分なRAMが確保されている場合、この値を適度に下げるのが有効です。一方、RAMへの負荷が高く、DBキャッシュが大きなデータベースサーバーでは、プロセスに十分な余裕を持たせるために、この値を高く設定するのが望ましいです。私は、実際のアクセス構成に合わせて設定を最適化できるよう、モニタリングデータを用いてこれらのパターンを個別に評価しています。.

静的ファイルが多数あるWebサーバー

CSS、JS、画像については、メタデータを キャッシュ. 50 から 80 の間の値は、ファイルの再オープンが高速化されるため、多くの場合有効であることが実証されています。トラフィックの急増時に発生する I/O ピークを厳密に検証し、変更前後の応答時間を比較します。レイテンシが安定し、404ルックアップコストが低下すれば、方向性は正しいと言えます。メタデータキャッシュが増加してもプロセスに十分な空き容量が確保されるよう、RAMの使用状況を常に監視しています。.

ファイルサーバーまたはNASシステム

多くのユーザーアクセスやディレクトリの変更では、以下の点が役立ちます より低い バランスの取れた値になるまで調整します。RAMに余裕がある場合は50～80程度に設定し、メモリが不足している場合は100に近い値に保ちます。ディレクトリの一覧表示がスムーズに動作するか、スナップショットやバックアップによってキャッシュが過度に押し出されていないかを確認します。ピーク時にI/Oレイテンシが増加する場合は、慎重に値を引き上げます。このようにして、操作の快適さと空きメモリのバランスを保っています。.

データベースサーバーとメモリ容量の少ないシステム

データベースは独自のバッファキャッシュを管理しているため、私は プロセスメモリ 通常は優先されます。120 から 200 の間の値を設定すると、VFS キャッシュを空にして RAM を解放するよう促すシグナルとなります。その際、アプリケーションのクエリ遅延やページフォルトのパターンに注意を払っています。システムのスワップが始まり、DBのパフォーマンスが低下している場合は、この値をわずかに引き上げると同時に、vm.swappinessも削減します。このアプローチにより、メタデータが不必要にスペースを占有するのを防ぎ、DBがそのスペースをより有効に活用できるようになります。.

ワークロードの例と目安

100から始めて、ウェブに近いものについては20ずつ減らしていきます ワークロード メモリを大量に消費するプロセスについては、20単位ずつ増やしていきます。各段階について、少なくとも1回のピークフェーズにわたってテストを行い、レイテンシ、キャッシュヒット、スワップアクティビティへの影響を確認しています。さらに詳しく知りたい方は、簡潔なページキャッシュ・パフォーマンス・ブースター私が並行して検討しているファイルキャッシュ戦略に関する補足情報です。測定値と目標値が一致した時点で、設定を固定し、主要指標を記録します。これにより、最適化のプロセスを再現可能に保ち、後で迅速に微調整を行うことができます。.

リスクと落とし穴

この値を低く設定しすぎると、カーネルはVFSエントリをほとんど解放できなくなり、ピーク時には OOM‑リスクにつながります。この値を高く設定しすぎると、メタデータを再読み込みする必要があるため、ファイルの検索やディレクトリの切り替え時のレイテンシが増加します。実際の負荷下でのテストを行わないと、負荷の低い時間帯のデータだけを見て誤った結論を導き出す恐れがあります。急激な変動は評価を困難にするため、私は段階的に進めています。原因を明確に把握できるよう、変更のたびに日時、負荷プロファイル、測定値を記録しています。.

モニタリングと指標

調整を行う価値があるかどうかは、厳しい指標. RAMの使用状況、キャッシュとプロセス間の割り当て、I/Oレイテンシ、およびスワップのアクティビティを監視しています。さらに、キャッシュヒット率やページフォールトの傾向を分析し、副作用を迅速に特定します。特に小さなファイルが多数ある場合、「Time-to-First-Byte」の改善が顕著に現れます。IOレイテンシが低く抑えられ、スワップが減少していれば、その方向性が正しいことが裏付けられます。.

チューニング・プレイブック：仮説から信頼性の高い設定へ

体系的なアプローチにより、手探りでの作業を回避します。結果の信頼性を高め、チームメンバーが各手順を把握できるよう、決まった手順に従って進めます。.

ベースラインを記録する: vm.vfs_cache_pressure=100、24～72時間の現実的な負荷。主要指標を記録する（レイテンシ：中央値／95パーセンタイル／99パーセンタイル、I/O待機時間、CPUスティール、スワップ活動、iノード／デントリーサイズ）。.
仮説を立てる：「小さなファイルが多い場合、ルックアップには時間がかかる――値を小さくすると処理が速くなる」または「RAMが不足している場合――値を大きくするとプロセスがスムーズに動作する」。.
段階的に変更する: ±20～±40ポイント。各段階につき、少なくとも1つのピークフェーズを測定する。.
比較する: SLO（例：95パーセンタイル）が確実に改善しているかどうかを確認し、, なしスワップやOOMイベントの発生が増加。.
ロールバック基準: 95パーセンタイル／99パーセンタイルのレイテンシが上昇したり、I/O待ち時間が長くなったり、キャッシュミスが頻発したりした場合は、一歩引き直します。.
フリーズとドキュメント: 最終値、日付、負荷時間帯、および主要指標を記録する。.

# 制御された測定ウィンドウのための簡易テスト（メンテナンス時のみ！）
# 実施前：主要指標のスナップショットを取得
date; free -h; grep -E 'InodeCache|Cached' /proc/meminfo; vmstat 1 5

sudo sysctl -w vm.vfs_cache_pressure=80
# 負荷テスト／ピークを待ち、その後、メトリクスを再度取得して比較する

ファイルシステムとマウントオプション：文脈が重要

vm.vfs_cache_pressure の効果は、ファイルシステムやマウントオプションによっても異なります。私はこれらの要因を次のように評価しています：

リレイタイム／ノータイム: 頻繁な atime 書き込みを防ぎます。noatime を設定すると、大量の読み取り処理における I/O 負荷が軽減され、メタデータの利点がより顕著になります。.
怠け者: RAM 内のメタデータの更新を遅延させます。これによりピークが平滑化されますが、フラッシュのタイミングに影響を与えます。.
ext4 対 XFS 対 Btrfs: 異なるiノード構造とシュリンカーの挙動。私は常に測定している ターゲットFS上で, 、仮定をそのまま受け入れるのではなく。.
NFS／ネットワークファイルシステム: 属性のキャッシュと無効化は、VFSの利点を制限する可能性があります。その場合、積極的な解放（高い値）を行うと、リモートルックアップの回数が増加します。.
OverlayFS/FUSE: 多くの小さなメタデータ処理はVFSキャッシュの恩恵を大きく受けています。RAMに余裕がある限り、私はその値を中程度から低めに設定しています。.

コンテナおよびCgroupに関する事項

コンテナ環境では、vm.vfs_cache_pressure は ホスト全体で スイッチ。変更点は以下の通りです。 すべて ノード上のPodやコンテナ。そのため、私は慎重を期し、ノードレベルでチューニングを調整しています。.

ストレージの制限: Memory-Cgroups はプロセスキャッシュとページキャッシュを制限します。スラブメモリは、その割合に応じて算入される場合があります。私は、これに関連して Pod-OOM や Node-Pressure イベントが発生しているのを確認しています。.
ワークロードの構成: DBポッドとWebフロントエンドを同時に実行しているノードには、極端な値は発生しません。必要に応じて、役割を異なるノードに分割します。.
ロールアウト: まずCanaries（1つのノード）から始め、その後段階的に展開します。変更内容はNodeベースライン（sysctl.d）に記録し、影響を受けるデプロイメントにも注記します。.

特別なケース

原因が分かれば、いくつかのパターンを的を絞って対処することができます：

CI/ビルド・ジョブ: ファイルへのアクセスやディレクトリのスキャンが頻繁に行われる場合は、値を低く設定した方が効果的です。ノードが混在して使用される場合は、ジョブ終了後にこの値を元に戻します。.
バックアップ／スキャンウィンドウ: ディレクトリの検索処理が長引くと、キャッシュが上書きされます。一時的に、 より高い バックアップ中は、この値（例：180）を設定して、Dentries/Inodes が RAM を埋め尽くすのを防ぎます。その後、元の値に戻します。.
負のデントリー: 存在しないファイル（404）もキャッシュされます。VFSキャッシュのクリアが過度に頻繁に行われない場合、アクセスエラーが頻繁に発生するWebワークロードのパフォーマンスは、測定可能なほど向上します。.
ストリーミング／順次I/O: ここではページキャッシュが支配的です。値が低すぎると効果が薄く、RAMを無駄に消費してしまいます。私は100前後、あるいはそれより少し高い値に設定しています。.

# の例：フルバックアップ中は設定を少し強めに
sudo sysctl -w vm.vfs_cache_pressure=180
# バックアップ終了後、事前に算出された最適値に戻す
sudo sysctl -w vm.vfs_cache_pressure=60

自動化とガバナンス

テストが成功したら、その設定を標準ビルドに組み込みます。重要なのは、チームが次のことを理解していることです。, なぜ値が選択され、いつ（例：バージョン変更やワークロードの変更後など）確認する必要があります。.

コンフィギュレーション管理: 私は、各ロール（Web、DB、ファイルサーバー）ごとに /etc/sysctl.d/ に定義されたデフォルト設定を管理し、それらを一元的に配布しています。.
ドリフト制御: 定期的な監査により、実稼働データとリポジトリが一致しているかどうかを確認します。.
ランブックス: 測定手順、ロールバックの閾値、および緊急時の手順（例：100へのリセット）を記録しています。.

# ロール：Webサーバー（例）
cat <<'EOF' | sudo tee /etc/sysctl.d/50-web-vfs.conf
vm.vfs_cache_pressure = 60
EOF
sudo sysctl --system

vm.vfs_cache_pressure およびその他のカーネルパラメータ

良い結果は、以下の要素が相まって初めて生まれる vm.swappiness およびダーティページしきい値。スワップネスを低く設定する（例：10～20）と、プロセスをRAM内に保持しやすくなり、不必要なスワップを回避できます。 vm.dirty_background_ratio と vm.dirty_ratio を使って、書き込みのピークによってシステム全体がブロックされないよう、システムが変更されたページをいつ書き出すかを調整しています。これらの値は、メタデータの検索速度を維持しつつ、書き込み処理が計画通りに実行されるように調整しています。ファイルキャッシュの相互作用に関する簡潔な概要については、こちらを参照しています：ファイルシステムのキャッシュ機能の概要.

ホスティング環境とWordPressに関する推奨事項

多くのテーマ、プラグイン、メディアは、無数の小さなファイルを生成するため、強力な VFSキャッシュ 明らかに効果があります。最初は100から始め、RAMに余裕があれば80に下げ、その後60に下げ、応答時間、レイテンシの95パーセンタイル、およびCPUスティールを確認します。メモリに余裕があれば、50でテストを行い、夕方のピーク時やキャンペーン期間中に再度検証します。スワップやOOMキラーが作動することなくレイテンシが低下すれば、その設定を恒久的に適用します。並行して、ページキャッシュも監視し、両方のキャッシュが適切に補完し合うようにしています。.

概要

vm.vfs_cache_pressure を使って、 バランス 高速なメタデータ検索と空きRAMのバランスを、非常に的確に調整しています。Web関連のワークロードではこの値を適度に下げ、メモリを大量に消費するアプリケーションでは上げます。変更を行うたびに、I/Oレイテンシ、キャッシュヒット率、スワップアクティビティの測定値を記録しています。 vm.swappinessやDirtyパラメータと組み合わせることで、安定したメモリ管理を実現しています。これにより、Linuxファイルシステムキャッシュを効率的に活用し、負荷がかかっている状況でも応答時間を確実に低く抑えています。.