Linuxのページキャッシュはどのようにしてホームサーバーの繰り返し読み取りを高速化するのですか？

Linuxのページキャッシュは、最近アクセスされたファイルデータを既存のRAMに保持することで、ホームサーバーの繰り返し読み取りを高速化します。最初のアクセスはまだHDDやSSDに到達するかもしれませんが、同じキャッシュされたページへの後続のアクセスは、それらのページがメモリ上に残っている限り、再度ストレージから読み取る必要がなくなります。これにより、インストールされたメモリ容量を変えずにレイテンシが改善されます。

これは空きメモリではなく、十分なRAMの代わりにもなりません。カーネルはキャッシュされたファイルページとアプリケーションメモリのバランスを継続的に調整しているため、実際の効果は作業セットのサイズ、再利用、メモリ圧力、ダイレクトI/Oの選択、要求されたデータがまだキャッシュされているかどうかに依存します。新しいRAMを追加しなければ、カーネルは既存の容量の利用を改善するだけであり、アプリケーションがトレードオフなしに消費できる容量を新たに作り出すわけではありません。

Linuxのページキャッシュは何を保持しているのか？

ページキャッシュはカーネルによって管理されるメモリサイズ単位でファイル内容を保存します。通常のバッファードファイルの読み書きはこのキャッシュを通過し、同じカーネル機構がアプリケーション、ファイル共有サービス、コンテナ、多くのデータベースにサービスを提供できるため、各プログラムが別々のファイルキャッシュを構築する必要がありません。

LinuxはバッファードI/Oを、ファイル内容が読み書きのためにメモリにキャッシュされるデフォルトの経路として文書化しています。変更されたキャッシュデータは後で書き戻されるか、同期操作を通じてストレージに強制的に書き込まれます。

キャッシュは「cache」と呼ばれるユーザーが見えるフォルダーではなく、ファイルにバックされたページをキーにしています。メディアのメタデータ、アプリケーションのバイナリ、データベースのインデックスページ、頻繁に開かれるドキュメントなどがすべてキャッシュされる可能性があります。ディレクトリエントリやinodeは関連するカーネルキャッシュを使用しますが、それらは別のメタデータ構造であり、キャッシュされたファイル内容と混同してはいけません。したがって、ファイルのパス名の一部がまだ別のメタデータ処理を必要としていても、そのファイルはキャッシュされたデータページの恩恵を受けることができます。

なぜ2回目の読み取りは1回目より速いことが多いのか？

コールドリードはページキャッシュを見逃すため、カーネルは必要なブロックをストレージから要求し、返されたデータをメモリに配置しなければなりません。この最初の操作は、アプリケーションがデータを受け取る前にデバイスの遅延と転送時間を支払います。

ウォームリードは要求されたページがすでにメモリ上に存在しているため、物理的な読み取りを繰り返すことなくコピーやマッピングが可能です。この違いは、サムネイル、パッケージファイル、インデックス、共有ライブラリなど、転送量に比べてストレージの遅延が大きい小さく頻繁に再利用されるデータで特に顕著です。

再利用が本質的な条件です。大きなメディアファイルを一度ストリーミングすると、再度要求されないページでキャッシュが埋まり、二度目の読み取りの利点を生み出さずにより有用なエントリを追い出します。したがって、キャッシュベンチマークは意図的な繰り返しアクセスと一回通過の連続スループットを区別しなければなりません。また、クライアント側キャッシュとサーバーページキャッシュを分けるべきです。どちらのレイヤーも繰り返しのネットワーク読み取りを高速に見せることができるからです。

ページキャッシュはバッファード書き込みをどのように変えるのか？

バッファード書き込みは通常、RAM内のページを変更し、ストレージデバイスが新しいデータを永続化する前にそれらをダーティとしてマークします。これにより呼び出しプロセスは早く続行でき、カーネルは書き戻しをより効率的に結合およびスケジュールする機会を得ます。

Linuxのダーティページ閾値は、バックグラウンド書き戻しと書き込みを生成するプロセスが書き戻しに参加しなければならないポイントを区別します。この境界は、短いバーストが高速に見える一方で、持続的な書き込みは最終的にデバイスの排出速度に遅くなる理由を説明します。転送グラフは、初期のメモリ支援によるプラトーと完全なストレージパスのより低い持続可能な速度を示すことができます。

したがって、通常の書き込み呼び出しの完了は必ずしも耐久性のあるストレージの証明ではありません。永続性を必要とするアプリケーションは同期セマンティクスを使用し、電源障害はまだ不揮発性メディアに到達していないダーティデータに影響を与える可能性があります。ページキャッシュの速度は、コミットされたデータベーストランザクションや完了したバックアップと同等に見なしてはなりません。

キャッシュされたデータはいつRAM内の場所を失うのか？

キャッシュされたページはアプリケーション、カーネル割り当て、および他の回収可能なメモリと競合します。プレッシャーが増すと、Linuxはクリーンなファイルページを破棄できます。なぜなら、それらはストレージから再度読み込めるからです。ダーティページは安全にメモリを再利用する前に書き戻しが必要です。

この表は固定の速度向上を約束するものではなく、データパスの状態をモデル化しています。RAM容量、アクティブな作業セット、アクセス頻度、ファイルシステムの動作、ストレージ遅延が特定のリクエストがコールドかウォームかを決定します。同じファイルが部分的にキャッシュされている場合もあり、1つのリクエストがメモリヒットとデバイス読み取りを組み合わせることがあり、単純に1行に分類されないこともあります。

Linuxのページリクレイムは単純な「キャッシュ優先、スワップ後回し」ではなく能動的なポリシーです。ページリクレイムのドキュメントは、リクレイムポリシーがメモリプレッシャー下でのキャッシュ効率とCPU使用率に直接影響することを説明しています。

どのホームサーバーワークロードが最も恩恵を受けるか？

利用可能なキャッシュより小さい作業セットへの繰り返しアクセスが最も恩恵を受けます。例としては、同じウェブ資産の提供、メディアライブラリのメタデータの再オープン、共有アプリケーションコードの読み込み、アクティブなページがメモリに残るファイルバックされたインデックスの繰り返しクエリなどがあります。

大規模な一括バックアップ、連続インポート、RAMよりはるかに大きいデータセットは再利用の恩恵が少なくなります。リードアヘッドはストリーミングに役立ち、バッファードライトはバーストを平滑化できますが、キャッシュされたページが再利用されない場合、サーバーは最終的に持続的なストレージとネットワーク経路に制限されます。モデルやデータセットを一度スキャンして読み込むことは、ホットなインデックスや設定ファイルを繰り返し開くこととは異なります。

コンテナはホストのページキャッシュを自動的にバイパスしません。ファイルにバックされたページは依然としてホストのメモリを消費し、他のサービスと競合する可能性がありますが、cgroupの制限によりリクレイム動作が変わることがあります。複数のアプリケーションが同時に動作している場合、NASアプリケーションのパフォーマンスチェックは、カーネルの仕組みを証明することなく有用な運用の引き継ぎを提供します。

ページキャッシュの効果はどのように測定すべきか？

同じファイル範囲、リクエストサイズ、同時実行数、アプリケーションパスを使用して、コールドランと制御された繰り返しランを測定します。経過時間、ストレージ読み取り、ページフォルト、メモリプレッシャー、キャッシュ状態を記録し、異なるシステム負荷で実行された無関係なランを比較しないでください。アクセスがSMBまたはNFS経由で行われる場合は、サーバーが2回目のリクエストを受け取らない可能性があるため、クライアントのキャッシュ状態も記録してください。

キャッシュ容量の上下両方の作業セットを使用してください。小さなテストはウォームキャッシュの性能を誇張し、RAMよりはるかに大きなデータセットはユーザーが繰り返しアクセスする小さなホットセットの利点を隠すことがあります。コンテナのメモリ制限や競合サービスは実行間で一貫しているべきです。

効果が理解されており、混乱が許容される場合を除き、ベンチマークを出すためだけに本番サーバーのキャッシュをクリアしないでください。通常の動作はキャッシュの再利用に依存します。問題は「RAMはどれだけ速いか」ではなく「この実際のワークロードが回収される前にどれだけ頻繁にファイルページを再利用するか」です。

よくある質問

バッファ/キャッシュの使用率が高いとホームサーバーのRAMが不足しているということですか？

いいえ。多くのファイルバックキャッシュはアプリケーションがメモリを必要とするときに回収可能です。利用可能メモリ、回収、スワップの挙動を使ってプレッシャーを判断し、キャッシュされたすべてのバイトを永久に占有されているとみなさないでください。

SSDでもページキャッシュは重要ですか？

はい。RAMアクセスはデバイスコマンドを回避しレイテンシを減らせますが、その差はHDDほど大きくありません。価値は再利用と競合に依存し、ストレージ媒体だけに依存しません。

サーバーを高速化するためにページキャッシュをクリアすべきですか？

通常はできません。有用なキャッシュページをクリアすると、後のリクエストがストレージに戻され、回避可能なレイテンシスパイクを引き起こす可能性があります。キャッシュのドロップは主に制御されたテストや診断のための操作であり、日常的な最適化ではありません。

1つのコンテナがページキャッシュ全体を消費できますか？

ファイルアクセスはホストキャッシュを埋めることができますが、メモリコントロールグループはキャッシュページを計上し制限できます。適切な制限がなければ、大きな作業セットが他のサービスに有用なページを置き換えてしまうことがあります。

完了したバッファード書き込みは電源断に耐えられますか？

必ずしもそうではありません。ダーティページはまだ書き戻しを待っている可能性があります。耐久性にはアプリケーションの同期契約、正しいストレージスタック、フラッシュを尊重するハードウェアが必要であり、ページキャッシュの完了だけでは不十分です。

最終的な結論

Linuxのページキャッシュは、アクセス間に有用なファイルページが既存のRAMに残っている場合、繰り返しのホームサーバーの読み取りを高速化します。コールドからウォームへの違い、キャッシュの滞在時間、メモリプレッシャーを総合的に評価してください。利点は再利用から生じ、書き込みバッファリングや耐久性は別の問題です。これが測定可能な境界です。