...
ウェブホスティングのロゴ

Linuxの透過型ページキャッシュ：基礎知識と従来のページキャッシュとの違い

2つの文で、LinuxがRAM内のファイルアクセスを高速化する方法と、ある 透過型ページキャッシュ 管理負担を軽減するために、より大きなページ単位を採用しています。さらに、4 KiBのページを使用する従来のページキャッシュとの違いや、TLBへの影響、フラグメンテーション、およびワークロードの挙動についても解説します。.

中心点

  • ページサイズ: 4 KiB 対 2 MiB は、粒度と効率に影響を与える。.
  • TLB印刷: 大規模なサイトは掲載数を減らし、小規模なサイトは柔軟性を保っている。.
  • フラグメンテーション: 大規模なページには、連続したRAMが必要です。.
  • ワークロード: 順次処理では利益が大きく、ランダム処理では利益が小さくなる。.
  • コントロール: テストし、測定し、その後段階的に設定を行う。.

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

従来のページキャッシュは、頻繁にアクセスされるファイルページをメモリに保持し、読み取りアクセスを直接 RAM 行われます。通常、4 KiBのページ単位で動作し、各ページをキャッシュ内の独立した単位として管理します。これにより、多数の小さなファイルや、頻繁にアクセスされる大容量ファイルの一部が、SSDやHDDに負荷をかけることなく利用可能な状態を維持できます。 カーネルはアクティブなページを優先し、アクセス頻度の低いコンテンツをキャッシュから排除することで、負荷のピークに動的に対応します。より詳細な背景については、以下の簡潔な入門記事をご参照ください。 ページキャッシュのパフォーマンス, 、その基本原理を実践的に解説したものです。.

なぜ透過的なページキャッシュなのか？

多数の4 KiBページが存在すると、管理作業が増え、 アドレスへんかんバッファ. 2 MiB のような大きなページは、より少ないエントリで同じアドレス空間をカバーできるため、CPU 時間を節約できます。透過的なページキャッシュは、アクセスパターンやメモリ配置が許す場合、ファイルページを自動的により大きな単位にまとめる仕組みです。 これはTransparent Huge Pagesの背後にある考え方に似ていますが、ここでは匿名メモリではなくファイルベースのキャッシュを指しています。私は、アクセスパターン、フラグメンテーション、およびレイテンシ要件を理解した上で初めて、このような機能を採用します。なぜなら、ページサイズを大きくすると粒度が高まるからです。.

違いを体系的に比較する

明確に区別できるよう、従来のキャッシュ、透過型ページキャッシュ、THPの主な特徴を並べて比較し、状況に応じた選択ができるようにします。 ワークロード より簡単になります。焦点は、ページサイズ、TLB、断片化、利点とリスクにあります。 この表は、マーケティング的な美辞麗句を排して、長所と限界を示しています。私はこれを左から右へと読み進め、どの列が負荷に最も適しているかを確認します。その後、4 KiBキャッシュのままにするか、より大きなページサイズを試すかを決定します。.

特徴 従来のページキャッシュ (4 KiB) 透過的なページキャッシュ（例：2 MiB） THP（匿名メモリ）
ページサイズ／粒度 きめ細やかで、極めて正確なキャッシュ 大まかに、かなり広い範囲 大まかな、大きなヒープ／スタック
TLB印刷 エントリ数が増えることで上位に表示される 下へ、表示件数を減らす 下へ、表示件数を減らす
管理費 多くのページで高い メタデータの削減 メタデータの削減
フラグメンテーション 非クリティカル、連続性は不要 連続したRAM領域が必要 連続したRAM領域が必要
適切な荷重 小さなファイル、ランダムアクセス 大容量ファイル、連続的なパターン 大きなヒープ、RAM上のデータベース
リスク TLBおよびCPUのオーバーヘッドの増加 オーバーフェッチ、スプリット／マージ時のレイテンシの急上昇 オーバーフェッチ、スプリット／マージ時のレイテンシの急上昇
カーネル／機能の依存関係 幅広く利用可能 バージョン／実装に注意する 配布設定を確認する

この表は検査の代わりにはなりませんが、私の考えを整理するのに役立ちます。 決定. まず、アクセスパターンとファイルサイズを評価します。次に、大きなページがある場合とない場合で、レイテンシ、CPU時間、キャッシュヒット率を測定します。ベンチマークの結果に外れ値がなく明確な利点が示された場合は、慎重にスケールアウトを行います。ピークが発生した場合は、元に戻すか、利用範囲を制限します。.

カーネルが大きなファイルページをどのように形成するか

ページキャッシュ内に大きなページ単位のブロックを形成するためには、カーネルはメモリ内の連続したファイル領域と、十分な一貫性のあるアクセスを必要とします。典型的な例として「プロモーション」が挙げられます。これは、複数の4 KiBのページが1つの大きなフォリオに統合されるプロセスです。 逆に、不適切なアクセスパターンが見られる場合は、より小さな単位へと分割（スプリット）が行われます。私は特に負荷がかかっている状況下でこれらの遷移を観察しています。なぜなら、プロモーションとスプリットは一時的にCPUリソースを消費し、LRUリストを更新するからです。順次アクセスを行う読み取り処理はプロモーションを促進しますが、アクセスがばらつくワークロードはスプリットを引き起こしやすくなります。.

この際、リードアヘッドが重要な役割を果たします。十分な量のデータを事前に読み込み、そのデータが実際に消費されれば、いわば副次的に大規模なフォリオが形成されます。一方、アプリケーションが予測不可能な小さな単位でデータにアクセスする場合、キャッシュは細分化された状態のままとなります。また、 ライトバック 大規模なページとの相互作用：関連するダーティ・ページを多数同時に書き戻すと、スループットとIOPSが向上する可能性がありますが、バーストサイズも増加します。そのため、私はダーティ・チューニング・パラメータ（例：. vm.dirty_background_bytes そして vm.dirty_bytes)、過大なフラッシュ波を避けるため。.

ファイルシステム、I/Oパス、およびそれらが及ぼす影響

バッファ付きI/Oはページキャッシュの恩恵を直接受ける一方、ダイレクトI/O（O_DIRECT) はその影響をほぼ回避します。したがって、意図的にダイレクトI/Oを利用するデータベースやバックアップツールの場合、透過的なページキャッシュの影響は比較的小さいと言えます。 mmap() その効果はアクセスパターンによって異なります。ページ単位で順方向にスキャンする場合は、大きなフォリオを有効に活用できますが、ランダムなジャンプではそうはいきません。 posix_fadvise() カーネルに指示を与えることはできますか（例：. SEQUENTIAL, WILLNEED, RANDOM)、リードアヘッドや置換を制御するものです。こうしたヒントは保証ではありませんが、キャッシュが自分のワークロードに適している可能性を高めてくれます。.

ファイルシステムには、それぞれ固有のヒューリスティックが備わっています。一部のシステムでは、ext4 や XFS はシーケンシャルなデータストリームに対して非常に合理的な動作を示しますが、重複排除や圧縮機能を備えたコピー・オン・ライト型ファイルシステム（例えば、多数のスナップショットを持つツリー構造など）は、異なる実行プロファイルを示します。 そのため、ファイルシステムのレイアウトや断片化の状況が、大きな連続領域の確保を可能にするかどうかを確認しています。著しく断片化されたデータに対してデフラグを実行すると、目に見えるメリットが得られる場合がありますが、常に慎重に、かつメンテナンスウィンドウを考慮して計画する必要があります。.

ハードウェアの要素：アーキテクチャ、NUMA、およびデバイス

すべてのアーキテクチャが4 KiBをベースページとして使用しているわけではありません。ベースページがより大きいシステムでは、デフォルト設定だけで粒度やTLBの挙動が変化します。これにより、キャッシュ内の大きなフォリオが効果を発揮する範囲がずれます。また、NUMAトポロジーにも注意を払っています： 大きなページは、I/Oスレッドやアプリケーションを実行しているCPUのローカルに配置されている場合に最も効果を発揮します。そのため、私はワーカーをノードにバインドし、NUMAごとの統計情報を監視し、不要な遠隔アクセスを防止しています。Linuxでは、ノードごとのメトリクス（/sys/devices/system/node/node*/meminfo) およびスケジューラー・ピニングにより、局所性を維持する。.

デバイス側では、コントローラーのキュー、NVMeの深度、およびレイテンシ曲線を確認します。 大規模なページは、高いスループットと安定したレイテンシで良好に動作しますが、テールレイテンシの急上昇には敏感です。バースト負荷を平滑化するI/Oスケジューラが、ここで決定的な役割を果たします。リードアヘッド値（blockdev --getra/--setra) 各デバイスおよびワークロードごとに、慎重にキャリブレーションを行います。.

測定手法、KPI、および観測可能性

事前に、数は少ないが意味のある指標をいくつか定義します： ページフォールト率、キャッシュヒット率、リクエストあたりのCPU時間、TLB負荷、リードアヘッドヒット率、レイテンシパーセンタイル（P50/P95/P99）、およびI/Oミスキュー。システム全体の概要を把握するために、私は vmstat, sar -B, iostat そして pidstat, 、トレンドを見極めるために。. /proc/meminfo そして smaps メモリ上にアクティブに格納されている内容を解析するのに役立ちます；; スラブトップ メタデータのオーバーヘッドを示しています。必要に応じて、以下で測定します。 パーフェクト 実際の負荷下でのTLBミスとCPUサイクル数を測定し、大きなページが及ぼす影響を可視化する。.

私にとってのテスト実行は、3つのフェーズで構成されています。ウォームアップ（安定したヒットレートに達するまで）、制御された負荷下での測定間隔、そしてエヴィクションとライトバックを観察するためのクールダウンです。私は、同一のデータセットを使用し、パラメータ（例：リードアヘッド、THPモードなど）を変更しながら、実行を繰り返します。 常に／誤ったアドバイス／決して)、信頼性の高い結果を得るためです。外れ値は無視しません。平均値が下がっているにもかかわらずP99が悪化している場合、その設定はたいてい私の目標範囲に合致していないことになります。.

実務における典型的なパターン

ストリーミングやメディア関連のワークロードでは、大容量ファイルの読み取りが主に順方向で行われます。ここでは、TLBへの負荷や管理オーバーヘッドが軽減されるため、大容量のフォリオが常に優位性を発揮します。長いシーケンシャルブロックを用いたバックアップ／リストアやレプリケーションも同様の利点があり、特に複数のプロセスが同じ領域を読み取る場合にはその効果が顕著です。 機械学習パイプラインは、データセットをまとめて保持することで恩恵を受けますが、多数の微小なファイルから高度にランダムなサンプリングを行う場合、事前に連続したブロックを含むコンテナ形式に移行しない限り、その効果は弱まります。.

何千もの小さなファイルを含むビルド環境やCI環境では、通常、4 KiBの粒度の方がパフォーマンスが向上します。こうした環境では、頻繁に使用される断片を迅速かつ正確に利用可能にすることが重要です。 私は、カーネルで大きなページサイズを強制するのではなく、Active(file)用に十分なRAMを確保し、デバイスごとに適切なリードアヘッドを設定し、場合によってはアプリケーションに近いキャッシュ（例：依存関係キャッシュ）に投資することを重視しています。.

リソース制御：Cgroups とワーキングセット保護

マルチテナント環境では、サービスごとにメモリを制限・保護しています。cgroup v2 を使用すれば、ページキャッシュを多用するプロセスの負荷を正確に計測でき、必要に応じて メモリ.low 保護することで、重要なワーキングセットが置き換えられる頻度を減らします。. メモリ.high 緩やかな上限を設定し、, メモリ.max 厳しい制限。複数のサービスが同じホストキャッシュを共有する場合、フェアネスとエヴィクションがどのように作用するかを観察しています。ページサイズを大きくすることでCPUの負荷を軽減できる一方で、エヴィクションによる大きなデータ塊が生じる可能性もあります。そのため、保護限界値を少しずつ調整し、LRUの動態を確認しています。.

不具合の症状と対処法

プロモーションとスプリットが頻繁に発生する場合、レイテンシの変動、カーネルCPUの使用率の上昇、ヒット率の変動が見られます。対策：リードアヘッドを調整する、スプリットの連鎖を避ける、ワークロードを分離する、または大きなページの積極性を抑える。 オーバーフェッチの兆候（キャッシュ率の高さ、スワップ圧力の増加、小規模なホットセットのヒット率の低下）が見られる場合は、より細かい粒度に戻すか、大規模な読み取り処理を専用のノードに隔離します。 ライトバックバーストによってテールレイテンシが増加する場合は、ダーティバイトの閾値をより厳しく設定し、フラッシュ間隔を平滑化します。.

NUMAジッターについては、CPU/メモリのピンニングと、I/Oスレッドの適切な配置によって解決しています。 TLBミスが発生しているにもかかわらず、アプリケーションの動作が依然として遅い場合は、ロックの競合、ファイルシステムのロック、およびスタック内での圧縮・復号の影響を確認します。大きなページサイズによるパフォーマンスの向上は、アプリケーションのエンドポイントでその効果が現れて初めて、真の成功と言えます。.

テストのための実用的なスケジュール

まずはベースラインから始めます：現在のカーネル、THPステータス（/sys/kernel/mm/transparent_hugepage/）、リードアヘッド値、I/Oスケジューラ、ファイルおよびディスクのレイアウト。次に、2～3つの具体的な仮説を定義します（例：「順次メディアストリーム：-10% CPU、より安定したP99」）。 続いて、現実的なトラフィックパターンを反映した固定のデータセットと負荷プロファイルを定義します。各テストシリーズには、同一のウォームアップ時間、同一の継続時間、および同一のメトリクス収集が適用されます。.

私は毎回、1つのパラメータのみを変更しています。最初はリードアヘッド、次に大容量ページの処理の積極度、最後にLRU/ダーティ設定です。 各ステップの後に、メトリクスとメモを保存し、後のカーネル更新時にも比較が可能になるようにしています。2回の独立した実行で同じ傾向が確認され、P95/P99のレイテンシが安定して初めて、その変更を限定的な本番環境グループに展開します。 明確な閾値（例：「P99が5分間『+15%』を超えた場合」など）を定めたロールバック計画は、常に不可欠です。.

アクセスパターンと機密性

大容量ファイルを扱うシーケンシャル読み取り処理では、より大きな ページ数. 多数の小さなファイルへのランダムアクセスは、キャッシュが必要なフラグメントのみを保持するため、通常4 KiBの方がパフォーマンスが向上します。混合負荷の場合は、合成テストでは結果が楽観的になりがちであるため、現実的なデータセットを用いた測定が必要です。私は、オーバーフェッチによって他の場所で不足するメモリが占有されていないか注意を払っています。 CPU時間のわずかな向上は、それによってLRUへの負荷が高まり、レイテンシが急増するのであれば、意味がありません。.

多数の小さなファイルを含むウェブホスティングのシナリオ

一般的な共有ホスティングでは、大量の小さなスクリプト、画像、アセットを処理しますが、4 KiBのキャッシュで十分に ハンドル 。ファイルサイズは2 MiB未満であることが多く、また不定期に利用されるため、大きなページサイズはここではほとんど付加価値をもたらさない。 その代わりに、十分なRAM、デバイスごとの適切なリードアヘッド、およびOPCacheのようなアプリケーションレベルのキャッシュに投資しています。さらに、静的アセットがブロックデバイスから読み込むよりもHTTPキャッシュを経由した方が高速に取得できるかどうかも確認しています。負荷プロファイルに大きなファイルが確認されて初めて、より大きなページキャッシュページへの道を開きます。.

データベース、キャッシュ、ログ

インメモリデータベースや大規模なヒープは、匿名モードでのTHPによって多くの場合恩恵を受ける メモリ. ファイルベースのエンジンや、長時間の順次読み取りが行われるログパイプラインにおいては、透過的なページキャッシュも有効です。 ページフォルトが減少するか、CPUの負荷が低減するかを再現性のある方法でテストしています。同時に、オーバーフェッチによって使用済みRAMが増加するか、コールドスタート時間が変化するかも観察しています。最初に簡単に説明しておくと、私はこのガイドを以下の目的で使用しています： THPを評価する および相互作用を正しく評価すること。.

仮想化とコンテナ

複数のVMやコンテナがホストカーネルを共有し、それによって ページ-キャッシュ。頻繁に使用されるバイナリやライブラリは、同じキャッシュからすべてのインスタンスに供給されるため、I/Oの負荷を軽減できます。ゲスト内のTHPはCPU負荷を軽減できますが、NUMAゾーンやオーバーコミットへの配慮が必要です。 大きなページがシステム全体を横断して移動しないように、NUMAノードごとに測定を行っています。負荷がかかった際にジッターが発生した場合は、曲線が再び滑らかになるまで、アグレッシブ度（madvise）を下げるか、THPを選択的に無効にします。.

設定を確認し、適切な値に設定する

まずは冷静に インベントリー: カーネルのバージョン、デフォルト設定、マウントオプション、リードアヘッドの値は？THPの状態は /sys/kernel/mm/transparent_hugepage/ で確認しています（例：enabled、defrag、khugepaged）。 ページキャッシュの挙動については、/proc/meminfo、ノードごとの統計情報、およびブロック単位のリードアヘッドを確認します。変更は決して盲目的に展開せず、実際のデータを用いてステージング環境でテストします。その後に初めて、安定した設定を本番環境に適用します。.

微調整：リードアヘッド、エヴィクション、モニタリング

大きなページは、リードアヘッド、I/Oスケジューラ、およびLRUが適切に機能している場合にのみ効果を発揮する 一緒に実行します。ページフォールト率、ミス、CPU時間、そして大きなページの分割・統合時に発生する可能性のあるレイテンシの急上昇を監視します。負荷がかかった状況では、キャッシュが古いページをどれくらいの速さで追い出すか、また重要なファイルがキャッシュから外れてしまうかどうかに関心があります。キャッシュの追い出し状況を調べる上で良い出発点となるのが、以下の記事です。 メモリ不足による強制終了, そこで典型的なパターンを説明します。その後、リードアヘッドやファイルシステムのオプション、必要に応じて大ページの使用設定を慎重に調整します。.

誤解を排した診療チェックリスト

まずは明確な目標から始めます：CPU使用時間の削減、レイテンシの低減、適切な ヒット率 ページキャッシュ内。その後、測定ポイントを定義し、ピーク負荷や混合負荷が見られる実際のワークロードを選択します。続いて、より大規模なページを段階的にテストします。まずはステージング環境で、その後、本番環境でも限定的にテストを行います。オーバーフェッチ、フラグメンテーション、またはジッターが発生した場合に備え、ロールバック計画を準備しておきます。 最後に、セットアップを再現可能に保ち、将来のカーネルアップデートを評価できるように、その効果を文書化します。.

簡単にまとめると

多くのアプリケーションにおいて、従来の4 KiBキャッシュは依然として信頼性の高い ベース, 、それは細かくてRAMを節約するからです。透過的なページキャッシュは、大きなファイルを順次読み込む際にTLBへの負荷とメタデータを軽減します。THPは匿名のメモリ領域を処理し、大規模なヒープの負荷軽減に役立ちますが、レイテンシの急上昇が生じる可能性があるため、注意が必要です。 私はデータに基づいて決定を下します。つまり、測定し、比較し、それから展開するのです。この手順を踏むことで、予測可能な応答時間、合理的なRAM使用率、そして明らかに安定したCPU動作を実現できます。.

現在の記事