コンテンツにスキップ 
Linux ページキャッシュは、頻繁に使用されるデータを RAM に保持することで、高価なデバイスアクセスを回避するため、ホスティングワークロードのファイル読み取りおよび書き込みの速度を決定します。その仕組みについてご説明します。 ファイルシステム Linux ホスティングでのキャッシュは機能します。重要な指標と、キャッシュを日常的に管理する方法についてご説明します。 サーバー負荷を増やす。.
中心点
- ページキャッシュ ファイルブロックを RAM に保持し、レイテンシを削減します。.
- ダーティページ 書き込みアクセスを収集し、まとめて書き戻します。.
- LRU-戦略は、新しいデータのために古いエントリを削除します。.
- モニタリング free、/proc/meminfo、vmstat、iostat を使用すると明確になります。.
- 最適化 RAM、ログローテート、Opcache、および適切な制限によって。.
Linux ページキャッシュとは何ですか？
Linux ページキャッシュは、頻繁に読み込まれるファイルブロックをメモリに保存し、それにより、そのファイルへの再アクセスを高速化します。 ファイル. RAMアクセスはマイクロ秒単位で実行されるのに対し、高速のSSDでさえミリ秒単位の時間を必要とするため、明らかに遅いため、私はすぐにその恩恵を受けることができます。 メモリ RAM で。アプリケーションがファイルを開くと、カーネルは読み込んだブロックをキャッシュに保存し、今後のリクエストにはメモリから直接応答します。これはプログラムに対して透過的に機能するため、何も調整や再設定を行う必要はありません。Web サーバー、PHP-FPM、画像配信、ログ読み取りプロセスなどのホスティングワークロードは、常にキャッシュにアクセスし、I/O を節約します。.
キャッシュは読み取り時にこのように動作します
ファイルを初めて読み込むとき、システムはブロックをキャッシュに読み込み、それらをホットとしてマークします。これにより、繰り返しアクセスしても利用可能であり、 時間 2番目の要件では、非常に短い時間しかかかりません。100 MB のファイルを 2 回続けて読み込むと、2 回目は実質的に RAM から完全に読み込まれます。 カーネルは、LRU（Least Recently Used）などの戦略を採用し、最後に使用されたエントリを優先的に処理することで、最新の Web コンテンツをキャッシュに長く保持し、使用頻度の低いデータを排除します。このロジックは、ホスティングのパターンにうまく適合します。なぜなら、多くの訪問者は、私が キャッシュ 迅速に配信します。ヒット率はキャッシュサイズ、つまり利用可能な RAM によって増加します。.
書き込みとダーティページについてわかりやすく説明
書き込み時には、データはまずキャッシュにダーティページとして保存されます。つまり、カーネルがまだディスクに書き戻していない変更されたブロックとして保存され、私は ライトバック-メカニズムをタイムリーに同期させることができます。この動作はライブで簡単に確認できます。dd を使用して 10 MB のファイルを作成すると、カーネルが SSD に一括で書き込むまで、ダーティ値が上昇します。 手動で sync を実行すると、システムはキャッシュの一貫性を確保し、ダーティメトリックをゼロにリセットします。このバンドルは、多くの小さな操作を大きな転送にまとめ、I/O を節約します。 パフォーマンス 書き込みプロセスごとに改善されます。最新のデバイスごとのライトバックアプローチにより、並列ディスクが独立して動作し、待ち時間が短縮されます。.
キャッシュアーキテクチャ：Dentry/Inode 対 ページキャッシュ
全体像としては、Linux はファイルデータだけをキャッシュしているわけではないということです。実際の ページキャッシュ コンテンツには、ディレクトリ構造、ファイル名、メタデータを RAM に保持する Dentry キャッシュと Inode キャッシュがあります。これらは、高価なパス解決や Inode 検索を節約します。 free -m これらの持分の価値は キャッシュ また、 バッファ むしろブロックデバイス関連のバッファを意味します。/proc/meminfo では、より詳細に分類されています（例：Dentries、Inactive(file)、Active(file)）。多くの小さなファイルを含むホスティングワークロードの場合、これらのメタデータキャッシュは、HTTP リクエストごとの実際のデバイスアクセス数をさらに削減するため、不可欠です。.
指標を正しく読み取る
まず free -m を確認し、キャッシュの列と Mem および Swap の行に注目して、キャッシュの効果を確実に評価し、実際の 使用方法 理解する。/proc/meminfo から、Cached、Dirty、Writeback、Buffers などの値を読み取り、これらを総合してメモリの状態を把握します。vmstat 1 は、システムが I/O を待機しているかどうかを常時表示し、iostat はデバイスごとの詳細情報を補足します。重要な点：Linux は空き RAM をキャッシュとして使用しますが、アプリケーションは必要に応じてすぐにそれを要求できるにもかかわらず、一時的に使用済みとしてマークします。 したがって、私は常に、以下を含む全体的な状況を評価しています。 ワークロード 単一の数字だけではなく。.
| 指標 | 出典/コマンド | 意味 | 典型的な信号 |
|---|---|---|---|
| キャッシュ | free -m, /proc/meminfo | ファイルデータ用のRAM割合 | 頻繁なファイルアクセスで高い価値 |
| ダーティ | /proc/meminfo | まだ書き戻されていないページ | 集中的な書き込み時には上昇し、同期後に下降 |
| ライトバック | /proc/meminfo | アクティブな書き込み操作 | フラッシュフェーズにおけるゼロ以外の値 |
| bi/bo (vmstat) | vmstat 1 | ブロックI/O入力/出力 | スパイクはキャッシュミスまたはフラッシュを示しています。 |
| r/s、w/s (iostat) | iostat -xz 1 | 1秒あたりの読み取り/書き込み操作数 | ミスでのジャンプ、一定のバックグラウンドノイズは問題なし |
ホスティングの日常におけるメリット
十分に満たされたページキャッシュは、I/O 待ち時間を大幅に短縮し、データアクセスをディスクから RAM に移行します。これにより、個々のリクエストのレイテンシが大幅に短縮され、 応答時間 ウェブサイトの表示速度を大幅に低下させます。頻繁に使用される画像、CSS、HTML ファイルはキャッシュに保存されるため、ウェブサーバーは SSD を経由せずにこれらのファイルを提供します。トラフィックが多い場合、ヒット率が重要になります。リピートユーザーが多いほど、そのメリットは大きくなります。 並行性の高いシナリオでは、キャッシュがストレージレベルを軽減し、負荷のピークを平準化します。 メモリキャッシュ、Web キャッシュ、プロキシキャッシュの関連性をより深く理解するには、以下をご覧ください。 キャッシュ階層, 各レベルを効果的に活用し、 リソース 無駄にしないでください。.
キャッシュサイズをスマートに制御
私は、2つの方法でキャッシュ効果に影響を与えています。RAMを増やし、不要なファイルアクセスを減らすことで、ホットデータ用のスペースを確保し、カーネルが適切なブロックを キャッシュ Logrotate と Gzip を使って大きなログファイルを整理し、メモリ内のファイル量を減らして、ログが重要なウェブ資産を圧迫するのを防ぎます。 バックアップや SQL ダンプなどの大規模な単発転送は、可能な限り、オフピーク時に処理することで、重要度が低いものとしてマークしています。echo 3 > /proc/sys/vm/drop_caches を使用してカーネルキャッシュを手動でクリアするのは、テストでのみ使用しています。これは、生産的なキャッシュミックスを破壊し、 レイテンシー 一時的に増加します。最終的には作業量によって決まります。RAM に収まるほど、パフォーマンスは安定します。.
ダイレクト I/O、fsync、および整合性
すべてのアクセスがページキャッシュを経由するわけではありません。一部のワークロードは、O_DIRECT または O_SYNC を使用してファイルを開き、キャッシュを意図的に回避したり、即時の永続性を強制したりします。これは、二重バッファリング（データベースバッファプールとページキャッシュ）を回避したい場合や、レイテンシよりも一貫性を重視する場合に有用です。 Web およびメディアのワークロードについては、ヒット率がほとんどの場合に優勢であるため、通常は通常のバッファ付き I/O を採用しています。また、fsync を理解することも重要です。ログファイルに対して fsync を頻繁に実行するアプリケーションは、ライトバックサイクルを促進し、I/O のピークを発生させる可能性があります。 私は、可能であれば、そのような呼び出しをまとめて、アプリケーションのフラッシュ間隔を適切に設定して、 スループット 高く掲げる。.
マウントオプション：relatime、noatime など.
ファイルへのアクセスは、atime（アクセス時間）を更新し、追加の書き込みを引き起こす可能性があります。 relatime （今日の標準）では、Atime は必要な場合にのみ調整されるため、I/O が大幅に削減されます。Atime ベースのロジックが使用されていない純粋な Web ワークロードでは、私はよく ノータイム, 書き込みアクセスをさらに減らすため。また、パターンと CPU の余裕が許せば、適切なブロックサイズ、バリアのデフォルト値、必要に応じてファイルシステムレベルでの圧縮も実用的です。これらのマウントオプションは、不要なメタデータの更新が少なくなるため、キャッシュヒット率の向上に直接つながります。 メモリ-パスに負荷をかける。.
コンテナとcgroups：マルチテナント運用におけるページキャッシュ
コンテナホスティングでは、複数のワークロードがグローバルページキャッシュを共有します。cgroups によるメモリ制限は、コンテナごとに許可される匿名メモリ（ヒープ/スタック）の量を定義しますが、ファイルキャッシュはホストカーネルによって管理されます。コンテナが過熱して多くの新しいファイルを読み込むと、他のコンテナのキャッシュページが押し出される場合があります。 そのため、私はメモリおよび I/O 制御（memory.high、memory.max、io.max）を使用して、負荷のピークを平準化し、公平性を高めています。コンテナで頻繁に使用される OverlayFS は、追加のメタデータレイヤーをもたらします。これは、パス解決やコピーオンライトの書き込みパスに影響を与える可能性があります。 オーバーレイレイヤーによってレイテンシが顕著に増加するかどうかを意図的に測定し、静的アセットについては、追加のレイヤーを使用しないバインドマウントを検討しています。.
キャッシュの予熱と保護
再起動後や大規模なデプロイメント後、キャッシュは空になります。ホットセットをターゲットに設定できます。 予熱する, 需要の高いアセットを一度に順次読み込むことで、最初の数分間のコールドスタートのレイテンシを大幅に削減します。 その一方で、キャッシュの汚染は避けています。バックアップ、マルウェアスキャン、または大規模な順次コピーの実行ツールは、優先度を低く（nice/ionice）設定して読み込み、可能であれば Fadvise を使用して重要度が低い（DONTNEED）とマークして、実行後にページが消えるよう設定しています。これにより、キャッシュは Web トラフィックに焦点を当て、本当にホットな データ.
NUMA と大規模ホスト
NUMA システムでは、メモリの局所性が重要な役割を果たします。ページキャッシュは物理的にノード内にあり、リモートアクセスはレイテンシを増加させます。ファイルアクセスが頻繁なサービスについては、CPU とメモリのバインディングの一貫性に注意し、zone_reclaim_mode が適切かどうかを確認しています。 実際には、NUMA ノードごとに中央の Web および PHP プロセスをバンドルして、キャッシュの最も使用頻度の高い部分がローカルに留まるようにすることが、多くの場合有効です。同時に、大規模な Java またはデータベースプロセスが、独自のメモリ要件によってページキャッシュを圧迫していないかを監視し、その場合は RAM を拡張するか、ワークロードを分離します。.
NFS と共有メモリ
NFS や類似のネットワークファイルシステムを使用したクラスタ設定では、キャッシュの扱いがより複雑になります。ページキャッシュは消費ホスト上でローカルに作用しますが、別のノードでの変更はプロトコルを介して無効化する必要があります。そのため、私は、I/O を過度に発生させることなく一貫性を維持できるよう、属性キャッシュと無効化間隔を調整しています。 共有ストレージ上の静的な Web 資産については、キャッシュが不要にクリアされないように、再検証を制限し、デプロイメントをアトミック（例：ディレクトリ交換）にするのが有効です。可能であれば、ホットセットを個々の Web ノードに複製して、最大限の ヒット率 に到達する。.
Tmpfs と一時データ
セッションファイル、ビルド成果物、短いアップロードキューなど、一時的に頻繁に読み込まれるデータには、私は tmpfs これにより、デバイスアクセスを完全に節約し、ページキャッシュを事実上プライマリストレージレベルにすることができます。ただし、tmpfs のサイズ設定は慎重に行います。tmpfs は RAM（および場合によってはスワップ）を使用するため、tmpfs マウントが大きすぎると他のキャッシュのスペースを奪ってしまう可能性があるからです。 定期的なクリーンアッププロセス（systemd-tmpfiles など）により、データが蓄積されてメモリが不足するのを防ぎます。.
ワークロードパターン：小規模対大規模、順次対ランダム
理想的なキャッシュの挙動は、パターンに大きく依存します。頻繁に繰り返される小さなファイルは、LRU と高い割合によって最大のメリットを得ることができます。 Active(ファイル). 一方、一度だけ読み込まれる大きなファイル（バックアップ、メディアトランスコード）は、キャッシュを支配すべきではありません。 私は、ランダムアクセスを肥大化させることなく、順次リーダーの速度を上げるために、read_ahead_kb を適度に設定しています。静的ファイルが多い Web サーバーでは、ユーザースペースでのコピーを回避するために、ゼロコピーパス (sendfile、splice) を有効にしています。これにより、ページキャッシュがソケットに直接データを提供するため、CPU を節約し、レイテンシを平準化することができます。.
詳細な観察と症状
vmstat や iostat に加えて、必要に応じて、リクレイム統計（例：Active/Inactive、pgscan/pgsteal、/proc/meminfo 経由）を確認して、システムがページを積極的にリクレイムしているかどうかを確認します。 頻繁なメジャーページフォールト、IO 待機値の上昇、および持続的な高いライトバック時間は、キャッシュに負荷がかかっていることを示しています。このような状況では、まず作業量を減らすことができるか、RAM を増やすことができるかを確認します。 ミスが引き続き多い場合は、LRU メカニズムが適切なブロックを優先するように、データをセグメント化します（たとえば、使用頻度の低いアーカイブと頻繁に使用される Web 資産を分離するなど）。.
実践的な経験則
- を計画している。 RAM ホットセット（静的なウェブアセット + データベースのアクティブな部分）が 1～2 回収まるように。これにより、トラフィックのピーク時にキャッシュヒットの可能性が 2 倍になります。.
- スワッピングは徹底的に避けています。匿名ページがアウトソースされると、ページャーがページキャッシュとI/Oを争い、レイテンシが低下してしまうからです。スワップ性は適度に抑えています。.
- ログファイルはより短くローテーションし、古い世代は圧縮して、チャットログがウェブアセットとキャッシュのスペースを争わないようにします。.
- 多くのファイルを変更するデプロイメントを、少数のアトミックなステップにグループ化します。これにより、一度に無効化するキャッシュエントリが少なくなり、 ヒット率 高い。
ファイルシステムとキャッシュアクセス
ファイルシステムは、カーネルがデータを保持および書き戻す効率に影響を与えるため、Ext4、XFS、ZFS の特性を理解し、ワークロードに合わせて選択することで、 キャッシュ 最適な効果を発揮します。Ext4 は堅実なオールラウンドなパフォーマンスを発揮し、XFS は並列書き込み負荷で優れた性能を発揮し、ZFS は ARC などの独自のキャッシュレベルを備えています。パターン（多数の小さなファイル対大きなメディアオブジェクト）に応じて、メタデータと書き込みパスは異なる動作をします。プラットフォームを決定する前に、実際のワークロードを測定します。概要をコンパクトに把握するには、以下の記事をご覧ください。 Ext4、XFS、ZFS の比較 マウントオプションなどの設定を調整して、カーネルが不要な ミス 生産。.
データベース、Opcache、ページキャッシュ
MySQL および MariaDB では、InnoDB バッファプールがデータページとインデックスの大部分を処理し、ページキャッシュがファイルシステムブロックの処理をさらに高速化することで、全体的な I/O を削減します。 クエリ-レイテンシを削減します。ホットセットが収まるようにバッファプールを十分に大きく設定します。そうしないと、エンジンが不要なディスクアクセスを行うことになります。 PHP アプリケーションでは、バイトコード用に Opcache、アプリケーション関連データ用に APCu を組み合わせて使用することで、ページキャッシュへの負荷を軽減しています。静的アセットは引き続きファイルシステムキャッシュの対象となり、瞬時に読み込まれます。この階層化により、作業の重複が回避され、 CPU 動的な部分のために自由。.
モニタリングと診断
vmstat 1 でメモリと I/O の兆候をリアルタイムで監視し、iostat -xz 1 でデバイスごとに確認し、/proc/meminfo で Dirty、Cached、Writeback を確認して、原因を素早く絞り込み、的を絞って対処しています。 行為 できます。IO 待機値が常に高い場合は、ボトルネックが存在する可能性があり、まずキャッシュと RAM でその影響を軽減します。次に、ファイルシステム、RAID、または SSD ファームウェアが速度低下の原因となっているかどうかを調べます。IO 待機が依然として深刻な場合は、アプリケーションアクセスとキャッシュヒット率を分析します。診断手順の入門として、 IO待機を理解する, 症状と原因を区別し、的を絞った治療を行うために ステップ 導き出す。.
リスクのないチューニングパラメータ
私は、いくつかのカーネルパラメータのみを調整し、変更を慎重にテストしています。なぜなら、優れたデフォルト設定が存在し、多くの場合、わずかな修正で十分な結果が得られるからです。 効率性 を獲得します。vm.dirty_background_bytes は、システムが非同期書き込みを開始するしきい値を決定し、vm.dirty_bytes はダーティページの上限を決定します。 これらの値をパーセンテージではなくバイト単位で設定すると、RAM の拡張に関係なく安定した基盤が得られます。さらに、read_ahead_kb はブロックデバイスごとのデータの事前読み込みに影響し、順次読み取りを高速化しますが、ランダムアクセスでは影響はありません。私はすべてのステップを記録し、副作用があった場合はすぐに元の設定に戻します。 価値観 後ろの方。
最新機能の概要
Transparent Huge Pages (THP) は、ファイルバックページをより大きな単位にまとめることができ、ページあたりの管理コストを削減し、ワークロードが大きくて連続している場合に TLB に有利になります。 量 適合する。ランダムアクセスが多いホスティング環境では、メリットが保証されないため、その効果を慎重に確認しています。一方、永続ストレージは、非常に低いレイテンシを約束し、従来のページキャッシュフローを部分的に回避する新しいデータパスを開きます。ここではベンチマークを観察し、アプリケーションが新しいストレージクラスから実際にメリットを得ているかどうかを判断しています。初期の実験は、 ライブ-トラフィック。.
要約：私が得たもの
Linux ページキャッシュは、頻繁なファイル操作を RAM に移行することで、レイテンシを削減し、I/O 負荷を軽減し、ホスティングワークロードを高速化します。 スケーリング 改善しました。私は意味のある値を測定し、free -m の誤った解釈を認識し、/proc/meminfo、vmstat、iostat を使用して全体像を把握しています。 Logrotate、十分な RAM、適切なカーネル制限、PHP-Opcache を使用して、リスクの高い介入を行うことなくパフォーマンスを向上させています。アクセスプロファイルを考慮してファイルシステムを選択し、IO 待機時間を監視して、ボトルネックをタイムリーに解消しています。これにより、繰り返しアクセスされる Web アクセスをキャッシュに保存し、負荷を軽減しています。 メモリレベルを最適化し、ページを迅速に配信します。.
