サーバーと仮想マシン

Linuxのページキャッシュを理解する：キャッシュによるパフォーマンス向上

Linux ページ キャッシュは、ファイルへのアクセス速度を向上させるための直接的な手段だと考えています。なぜなら、キャッシュは、低速なストレージではなくRAMから繰り返し読み込みを行うからです。本記事では、カーネルがこれによってどのようにレイテンシを低減し、Webサーバー、データベース、WordPressなどのワークロードを高速化しているかを具体的に解説するとともに、簡単な方法でその効果を活用する方法についても紹介します。.

中心点

以下の要点は、私が ページキャッシュ 評価し、的確に活用する。.

RAMキャッシュ: ファイルデータはメモリに読み込まれ、アクセス時間を短縮する。.
戻入: 書き込み操作は「ダーティページ」としてまとめられることで、より効率的になる。.
透明性: アプリケーションは、コードを変更することなくその恩恵を受けることができます。.
ダイナミクス: キャッシュは、必要に応じてメモリを解放します。.
ワークロード: Web、DB、CI/CD、およびログの処理が著しく向上している。.

Linux ページキャッシュとは何ですか？

その意味は分かるのですが、 ページキャッシュ RAM内の記憶領域であり、プロセスが read(), write() 或いは mmap() ファイルにアクセスする。カーネルはアクセスがあるたびにまずキャッシュを確認し、データがすでに存在する場合はメモリから即座に提供するため、応答時間が目に見えて短縮されます。データがキャッシュに見つからない場合、カーネルはストレージからデータを読み込み、そこに格納してプロセスに提供します。これにより、次回のアクセス時には高速なキャッシュヒットが実現されます。このメカニズムは仮想ファイルシステムと密接に関連しており、アプリケーションにとっては透過的に動作するため、汎用的に利用できます。この動作原理から、次のような単純な原則が導き出されます。空きRAMを キャッシュ領域 そのまま使わずに放置しておくよりは。.

ページキャッシュがなぜ目に見えて処理を高速化するのか

最大の効果は、私が ディスクI/O 繰り返しアクセスされるデータがキャッシュに格納され、ストレージから再度読み込む必要がなくなると、アクセス回数が劇的に減少します。読み取りアクセスはRAMから行われるため、レイテンシやコントローラでの待ち行列が大幅に軽減されます。書き込みパスも同様に恩恵を受けます。カーネルが変更箇所を「ダーティページ」としてマークし、それらをまとめて後で効率的にストレージに書き込むためです。これにより、ストレージに負荷をかける多くの小さな個別のアクセスがなくなり、代わりに少数の大規模な操作が行われるようになります。総じて、短いウォームアップ期間を経ると、より多くの作業データが メモリ 残ります。.

読む、書く、ダーティ・ページズ：その流れはこうだ

読み取りアクセスは常にキャッシュチェックから始まるため、ヒットした場合は待ち時間なく処理され、ミスした場合はコストが1回で済みます。書き込みの場合、変更された内容はまずRAMに格納され、「ダーティ」状態として待機状態となり、カーネルがそれらを一括してストレージに転送するまでその状態を維持します。必要に応じて、以下のコマンドで永続的な保存を強制します。 fsync(), データに関しては、依然として重要なのは 一貫性 直ちに必要となります。このライトバックパスは、PHPコードや設定ファイル、アセットなど、多数の小さなファイルを扱うアプリケーションの効率を高めます。同時に、ライトバックはパフォーマンス向上につながる一方で、物理的にすべてが保存されるまでの短い時間差が生じる点にも留意しています。.

空きRAMはキャッシュであり、損失ではない

多くの人が「使用中」のメモリを懐疑的に見ているが、私は「buff/cache」の割合を妥当な指標として捉えることで、その値を正しく読み取っている。 バッファメモリ 値。カーネルは未使用のRAMを積極的に活用し、必要に応じて瞬時にプロセスに割り当て直し、リクレイム機構を通じてバランスを調整します。この動的な仕組みにより、キャッシュに十分なワーキングセットが残っている限り、システムは高速に反応します。アプリケーションの需要が高まると、カーネルは古いキャッシュページを追い出し、手動で介入することなくスペースを確保します。負荷の高い局面に入ると、私は特に以下の点に注目して状況を観察します。貯蔵圧力, 、状況を正しく評価し、ボトルネックを特定するために。.

大きな恩恵を受けるワークロード

データが頻繁に繰り返し使用され、多くの小さなアクセスが発生する場面こそが、最大のメリットがあると考えています。 キャッシュ 簡素化されます。典型的な例としては、頻繁に利用されるPHPやHTMLファイルを持つWebサーバーや、繰り返し使用されるテーマ、プラグイン、メディア、設定を備えたWordPressのインストール環境が挙げられます。データベースも、ページキャッシュを意図的にバイパスしない限り、ファイルシステムレベルでの繰り返しクエリにおいて恩恵を受けます。ビルドアーティファクトを扱うCI/CDシステムや、多数の小さなファイルを扱うツールも、同様に顕著な高速化をもたらします。順次読み取りを行うログ分析でさえ、RAMバッファによってパフォーマンスが向上します。これは、カーネルがアクセスパターンを保持し、より迅速に提供するためです。.

モニタリングと測定：キャッシュ効果の評価方法

まずは以下で確認します free -h, 、「buff/cache」のサイズがどれくらいか、そしてそれがどのように より多くの証拠がある 時間の経過とともに発展してきた記憶。その一端を /proc/meminfo 次のような主要指標を表示してくれます キャッシュ, ダーティ そして ライトバック, 、人気記事や未完了の執筆作業に関する情報を表示します。 iostat -x 1 或いは pidstat -d 1 キャッシュがウォームアップすると、物理I/Oの負荷が低下するかどうかがわかります。次のようなツールでは パーフェクト 或いは bcc-ベースのスクリプトは分析の深みを増すのに役立ちますが、明確なパターンが見て取れる場合は、日常業務で必要になることはめったにありません。さらに、ファイルへのアクセスを繰り返し実行して、2回目の実行が有意に高速化されるかどうかをテストしています。これは、 キャッシュ 確認されました。.

チューニング：パラメータと適切なデフォルト設定

私は理解できる範囲でのみ調整を行い、キャッシュのチューニングについては、数が少なく、理解しやすいものから始めます。 調整ネジ. vm.dirty パラメータは、RAM からメディアへの書き込みがいつ開始されるか、およびその処理がどの程度積極的に行われるかを制御します。. vm.vfs_cache_pressure カーネルがDentryおよびInodeキャッシュをどの程度上書きするかを決定し、ファイルシステム操作に直接影響を与えます。ブロックデバイスレベルでのリードアヘッド値は、ワークロードがそれに適している場合、シーケンシャル読み取りパフォーマンスを向上させることができます。私は各手順を記録し、負荷下でのテストを行い、パフォーマンスの向上が見られない場合は必要に応じて初期値に戻します。.

パラメータ	スタンダード	効果	いつ変更するか
vm.dirty_background_ratio	10%	非同期ライトバックフェーズの開始	初期段階で、多数の小さな書き込みを集中させる
vm.dirty_ratio	20%	RAM内の「dirty」の最大割合	バースト負荷時にバッファ容量を増やす
vm.dirty_expire_centisecs	3000	フラッシュまでの「ダーティ」時間（1/100秒単位）	レイテンシー目標については、より短い値に設定する
vm.dirty_writeback_centisecs	500	バックグラウンド・ライトバックの間隔	ストレージの動作が鈍い場合は、設定を少し引き上げる
vm.vfs_cache_pressure	100	デントリ／iノードを削除したいという衝動	多くのファイル操作において、
ブロック・リードアヘッド	端末によって異なる	順次読み込みプレビュー	ストリーミング読み取り数を増やす

回収および搬出のプロセスについてより深く理解するには、以下の内容を確認するとよいでしょう。ページキャッシュの追い出し, 、自身のセットアップを的確に評価するために。私は常に変更を段階的に行い、測定ポイントで経過を観察し、その効果を明確に記録するようにしています。そうすることで、誰もが カスタマイズ 理解できるままである。.

ページキャッシュとデータベース：いつバイパスするのが適切か

一部のデータベースでは、意図的に ダイレクトI/O 重複バッファリングを回避し、独自のキャッシュを活用するためです。このようなシナリオでは、DB内部のパラメータを調整し、Linuxのページキャッシュへの依存度を低くしています。エンジンが新しいデータや非常に大きなワークロードに頻繁にアクセスする場合は、メモリ使用量をより予測しやすくするために、バイパスモデルを採用する価値があります。一方、同じテーブルやインデックスからのファイルの繰り返し読み取りに重点が置かれる場合は、ファイルシステムキャッシュが依然として有用です。私は、一律のルールではなく、実際のアクセスパターンに基づいて判断を行うことで、 パフォーマンス 本当に上昇している。.

エヴィクション、リクレイム、およびメモリ使用率

高負荷時、カーネルはページをアクティブと非アクティブに分類します LRUリスト そして、キャッシュから候補を段階的に削除します。このリクレイム処理は、プロセス需要の増加、cgroupの制限、またはI/Oの待ち時間によって生じる負荷に応じて動作します。モニタリングでエヴィクションの増加とI/O負荷の上昇が同時に確認された場合、作業データセットが利用可能なRAM容量を上回っていることがわかります。このような局面では、ワークロードを分離するか、キャッシュ戦略を変更するか、あるいはメモリを増設するかを検討します。エヴィクションのルールを理解するには、以下の項目に関する体系的なガイドが役立ちます。貯蔵圧力, 、症状を正しく解釈し、対策を立てるために。.

実践：手っ取り早い確認とコマンド

第一印象として、まずは free -h そして、その割合を確認する buff/cache, 、その点について詳しく説明する前に。その後、ファイルスキャンの2回の実行結果を比較します。例えば、 見つける あるいはベンチマークを使用し、コールドスタートとウォームスタートの所要時間の差を観察する。. grep -E "Cached|Dirty|Writeback" /proc/meminfo キャッシュにどれだけのデータが格納されているか、そしてまだ書き込む必要があるデータがどれほどあるかを表示します。. iostat -xz 1 キャッシュが効き始めると、デバイスの負荷がどの程度か、またキューが減少しているかどうかが明らかになります。キャッシュの基礎に関する背景知識を知りたい方は、以下の概要をご覧ください。ファイルシステムのキャッシュ VFSとRAMバッファの相互作用を解説した、わかりやすい入門ガイド。.

よくある誤解を解く

„「RAMがいっぱいです。サーバーに問題があります」という言葉をよく耳にしますが、その キャッシュ これは原因ではなく、答えです。Linuxは、アプリケーションがメモリを消費すると柔軟にメモリを解放し、新しいデータが一時的に保存されるとすぐに再びそのメモリを割り当てます。手動で echo 3 > /proc/sys/vm/drop_caches 長期的なメリットをもたらすことはめったになく、測定結果を歪めてしまいます。むしろ、真のボトルネックを特定し、その箇所のI/Oパスの負荷を軽減する方が理にかなっています。また、ページキャッシュと、デントリ／iノード用のスラブキャッシュを区別することで、2つの異なる メカニズム 鍋に入れる。.

マウントオプションとファイルシステムの細かい点

ファイルシステムやマウントオプションがページキャッシュの効率に大きな影響を与えることを考慮しています。. 時間-更新処理は追加の書き込みを発生させます。 relatime （現在は標準）これを減らすことにします、, ノータイム アクセス時間に縛られることがなければ、さらに節約できる。. 同期そして dirsync 即時永続化を強制し、ライトバックの利点を無効にしてしまう――レイテンシが重要なメタデータの場合は妥当だが、それ以外の場合は避けるようにしている。ジャーナリングモード（例：ext4の場合 data=ordered 対 ライトバック）は、メディア上に実データがメタデータより先に書き込まれるか、後に書き込まれるかに影響を与えます。私は、見せかけのパフォーマンスよりも安全性を優先します。XFSとbtrfsは、メタデータやCoWの扱い方が異なります。CoW、圧縮、重複排除はI/Oを節約しますが、CPU負荷を高める可能性があります。そのため、私はワークロードを現実的に測定し、マウントオプションがアクセスパターンに合致しているかどうかを判断しています。.

コンテナ、VM、および重複キャッシュ

コンテナ内では、すべてのプロセスが同じカーネルを共有しており、したがって同じページキャッシュも共有します。これにより、ホットファイル（ライブラリなど）の共有が容易になりますが、厳格な cgroup の制限（メモリ.max) により、キャッシュページを早期に置き換えることができます。サービスごとにヘッドルームを確保し、 メモリ.low, 、重要なキャッシュをある程度保護するために。VM内にはにキャッシュ：ゲスト内、および場合によってはホスト側（ファイルベースのストレージの場合）。これにより、バッファリングが二重化されます。RawデバイスやDirect-Storageを使用すれば、ホストキャッシュを省略できますが、その利点は失われます。バルーニングとオーバーコミットはゲスト内のリクレイムに影響を与えます。継続的なバルーニングがキャッシュスラッシングを引き起こしていないかを監視し、リソースやサイズ設定を調整しています。コンテナストレージ（OverlayFS）では、デプロイメントがコールドスタートしないよう、頻繁に使用されるレイヤーを意図的にウォームアップしています。.

NUMA、cgroups、および分離

NUMAシステムでは、カーネルはノードごとにLRUリストを管理します。スレッドが主にローカルにアクセスする場合、ページキャッシュのヒット率は ヌマ・ナ そしてレイテンシを削減します。CPUおよびメモリのアフィニティ設定により、アプリケーションとそのデータが互いに近接するようにします。以下を通じて memcg (cgroups v2) では、ページキャッシュはグループに割り当てられます。一方、 メモリ.high 次のようにして、制御されたリクレイムを実行します。 メモリ.max 私は厳しい線引きを行い、そして メモリ.low 重要なサービスに優先順位を付けています。これらのツールは、負荷の高いバッチジョブによって、レイテンシに敏感なWebサービスのキャッシュが空になってしまうのを防ぐのに役立ちます。分離によって計画性が生まれますが、ヒット率が低すぎる小さなキャッシュが過剰に生成されないよう、バランスを調整しています。.

SSD、HDD、およびリードアヘッドの実践

リードアヘッドは、シーケンシャルなアクセスパターンでは有益ですが、ランダムアクセスでは多くの場合、単なる無駄になります。 HDDでは、通常、線形スキャンを高速化するためにリードアヘッドを増やします。高速なNVMe SSDではそのメリットは小さく、リードアヘッドが多すぎるとRAMを無駄にし、未使用のページが他のページを追い出すことでキャッシュヒット率が低下してしまいます。私はデバイスごとにリードアヘッドを調整し、繰り返し実行してスループットやレイテンシが改善されるかを確認しています。また、I/Oスケジューラにも注意を払っています。NVMeでは「none」や「mq-deadline」が一般的ですが、HDDではデッドラインスケジューリングが有効な場合があります。ページキャッシュはI/Oプロファイルを平滑化しますが、ブロック層もそれに適合している必要があります。目標は、キャッシュに主に有用で再利用されるデータを含めることであり、単に事前に読み込まれたバイトを格納することではありません。.

コールドスタート、プレウォーミング、およびデプロイメント

どのキャッシュにもウォームアップ期間が必要です。再起動やロールアウトの後には、重要なディレクトリを順次読み込むなどして、意図的にホットセットを読み込みます。これにより、デプロイ後の「コールドタイム」が顕著に短縮されます。ローリング戦略では、新しいインスタンスがキャッシュを充填している間もサービス全体が迅速に応答できるよう、少なくとも1つのウォームなインスタンスをオンラインに維持しています。ファイルツリーへの大規模な変更（パス変更など）は、デントリやiノードをコールド状態にしてしまうため避けています。その代わりに、ファイルの内容やパスがほぼ安定したまま保たれる、アトミックなシンボリックリンクの切り替えやコピー・オン・ライト戦略を採用しています。これにより、ページキャッシュが有効なままになるだけでなく、メタデータキャッシュの効果も維持されます。.

深さ方向の測定項目

そのほか /proc/meminfo 詳細な診断のために、私は /proc/vmstat: 以下のようなカウンター pgfault そして pgmajfault 軽度のページフォールトと重度のページフォールトを区別し、, nr_active_file/nr_inactive_file ファイルベースのワークセットのサイズを示し、 ワーキング・セット・デフォルト スラッシングの検出に役立ちます。デバイスのI/Oレートが高いままリファルトが増加する場合、ワークセットがRAMに収まっていないことを示しています。私は同じワークロードを2回実行してテストしています。キャッシュが有効であれば、2回目の実行は明らかに高速になるはずです。再現性のあるコールドスタートテストを行うため、キャッシュのクリアは実験環境でのみ行い、本番環境の測定結果を歪めないよう、その過程を明確に記録しています。私にとって重要なのは、単一の指標を過度に解釈するのではなく、時系列データからパターンを把握することです。.

スワップ、スワッピネス、スラッシングを回避する

負荷がかかると、Linuxは（それが妥当である限り）匿名ページにアクセスする前に、まずページキャッシュを解放します。プロセス用のメモリが不足し、かつ匿名ページに十分な空きがない場合、システムはスワップを開始します。ある 低すぎる スワップネスが高くなると、重要な匿名メモリ（ヒープ／スタック）が積極的に保持され、その代わりに有用なキャッシュページが追い出されることになり、I/O負荷が増大する可能性があります。ある 高すぎる スワップ率が高くなると、逆にスワップが早期に発生し、レイテンシのピークが生じやすくなります。私は適度な値を設定し、測定と監視を行います。目標は、ホットセットをRAMに残し、スワップに割り当てられるのは、使用頻度の低いコールドデータのみとし、ホットデータがスワップに割り当てられることが決してないようにすることです。.

安全性と耐久性：メディア上のデータ

ライトバックはパフォーマンスを向上させますが、変更内容がRAM上にのみ存在する短い期間が生じます。すぐに永続化が必要なデータについては、私は fsync() 或いは fdatasync(). また、書き込みバリアやジャーナリングといった安全なデフォルト設定を信頼しており、バリアを無効にするようなリスクの高いオプションは避けています。ストレージレベルでは、コントローラのキャッシュに注意を払っています。バッテリーやコンデンサを備えたライトバックポリシーは高速かつ安全ですが、保護機能のない不安定なキャッシュは扱いが難しいです。システム全体で強制される 同期 すべてのデータをフラッシュすること――これは、私が意図的に、かつ稀にしか使用しない大雑把な手法です。このようにして、ページキャッシュによる高速性と、ビジネス上重要な場面での確実な永続性を組み合わせています。.

WordPressとWebスタック：実用的なコツ

Webスタックには複数のキャッシュが組み合わされています。Linuxのページキャッシュは静的アセット、PHPファイル、設定ファイルの読み込みを高速化し、PHPのOpCodeキャッシュは実行パスとバイトコードをメモリ内に保持します。デプロイによってコードパスが頻繁に変更されないよう配慮し、アセットを統合することでファイルアクセスを削減しています。永続的なオブジェクトキャッシュ層がデータベースI/Oを低減することで、ファイルシステムキャッシュは残りのホットファイルに対してさらに効果的に対応できるようになります。セッションやトランジェントは、可能な限りローカルディスクには書き込まず、メモリキャッシュやネットワークキャッシュに保存します。これにより、ページキャッシュは、頻繁に読み込まれるその他のファイルに対してその強みを最大限に発揮できるようになります。その結果、物理I/Oが削減され、応答速度が向上し、レイテンシが安定します。.

簡単にまとめると

Linuxのページキャッシュのおかげで、ファイルへのアクセスが高速に行われています RAM また、データストレージへの高コストなアクセスも大幅に削減します。読み取りヒットはアプリケーションの処理を高速化し、ライトバック機能は多数の個別書き込みをまとめて処理することで効率を高めます。空きメモリは単に遊休状態になるのではなく、応答性の高いプラットフォームを実現するためのキャッシュとして機能します。以下のような測定指標により free -h, /proc/meminfo そして iostat パラメータなどの設定を行う前に、その効果を把握しています。 vm.dirty_ratio 或いは vm.vfs_cache_pressure 実行する。ワークロードを熟知し、変更を管理された環境でテストし、キャッシュを適切に活用すれば、顕著なパフォーマンス向上が得られる。 パフォーマンス コードを変更することなく。.