問題と適用シナリオ
あるLinuxサービスが起動時にmmapを使用して20 GiBの読み取り専用インデックスをマップし、その後8個のワーカープロセスをforkします。モニタリングでは以下の事象が確認されています。
- マッピング作成直後、各プロセスの仮想メモリは約20 GiB増加する。
- RSSは即座には同量増加せず、クエリがインデックスのより多くの領域にアクセスするにつれて上昇する。
- コールドスタート直後の最初のリクエストはレイテンシが高く、メジャーページフォルトが多く発生する。
- 同じクエリを繰り返すと高速になり、メジャーフォルトの発生数は大幅に減少する。
仮想アドレスが物理アドレスに変換される仕組み、TLBミスとページフォルトの違い、Linuxにおけるマイナーページフォルトとメジャーページフォルトの意味、そして8個のワーカーすべてのRSSを単純合算すると物理メモリ消費量が過大評価される理由を説明してください。最後に、ボトルネックを検証し、コールドスタートレイテンシを削減する方法を提示してください。
この問題は、バックエンド、インフラストラクチャ、システムソフトウェア、SRE、パフォーマンスエンジニアリングの面接に適しています。以下で使用する20 GiBのマッピング、8個のワーカー、4 KiBのページサイズは仮定の演習用設定であり、出典元の本番環境の測定値ではありません。インデックスは読み取り専用のファイルマッピングです。無名メモリ（anonymous memory）、書き込み可能なプライベートマッピング、コンテナのメモリ制限、リアルタイムシステムなどの条件が加わると、調査手順は変わります。
面接官が評価しているポイント
第1の評価ポイントは、候補者が4つのレイヤーを区別して理解しているかです。仮想アドレス空間はプロセスがアドレス指定できる範囲を定義します。ページテーブルは変換情報とパーミッションを保持します。TLBは最近の変換情報をキャッシュします。物理ページは現在RAM上に常駐しているデータを保持します。基本的な回答は「仮想メモリは物理メモリを超過できる」と述べるにとどまりますが、優れた回答はTLBヒット、ページテーブルウォーク、修復可能なフォルト、不正アクセスを含むロード命令の実行フローを順を追って説明します。
第2の評価ポイントは、TLBミスがページフォルトではないことを認識しているかです。変換情報がTLB内に存在しなくても、ページテーブルエントリが有効かつ常駐（resident）していれば、プロセッサはページテーブルウォークを完了してTLBを充填できます。ページフォルトは、非常駐ページ、コピーオンライトを必要とする初回書き込み、パーミッション違反など、現在のページテーブルの状態ではアクセスを満たせない場合に発生します。
第3の評価ポイントは、Linuxのカウンタの正確な解釈です。マイナーフォルトはディスクI/Oを必要としません。ページがすでにページキャッシュに存在するものの当該プロセスにマッピングされていない場合や、カーネルが無名ページを割り当てている場合、あるいはコピーオンライトを完了している場合などが該当します。メジャーフォルトはディスクI/Oを必要とします。スワップアウトされた無名メモリをロードする場合もありますが、ページキャッシュに存在しないファイルバックマッピングを読み出す場合もあります。したがって、「メジャーフォルト＝スワップ」という認識は誤りです。
最後に、面接官はエビデンスに基づく検証プロセスを求めています。優れた回答は、ウォームアップ、インデックス配置の変更、カーネルアクセスヒント、またはワーキングセットの縮小を選択する前に、リクエストレイテンシ、フォルトの増分、ファイルページの常駐状況、ブロックデバイスI/O、RSS/PSS、メモリプレッシャーを同一の時間枠で関連付けて分析します。
回答前の前提確認の質問
- これはファイルバックメモリですか、それとも無名メモリですか？マッピングは
MAP_SHAREDですか、MAP_PRIVATEですか？ 読み取り専用ファイルページはページキャッシュを介して共有できます。プライベートな書き込み可能ページは、コピーオンライト後にプロセス固有になる場合があります。 - ホットなワーキングセットのサイズはどの程度で、アクセスはシーケンシャルですか、それともランダムですか？ リクエストの95%が2 GiBのホット領域のみにアクセスする場合、20 GiB全体をウォームアップすると起動時間とメモリのプレッシャーが増加します。シーケンシャルスキャンとランダムルックアップでは、適切な先読み（read-ahead）の選択肢も異なります。
mmapはforkの前と後のどちらで実行されますか？ どちらのアプローチでも同じファイルをマップできますが、forkの前にマップすると、ワーカーが単一の設定を継承しやすくなります。ただし、各プロセスは依然として独自のページテーブルとTLB状態を保持します。- メジャーフォルトはブロック読み取りやテールレイテンシと同時に増加していますか？ コールドスタートのコストの大半がデマンドページングによるものと判断する前に、その相関関係を確認する必要があります。CPU飽和、ロック、リモートストレージ、インデックスの初期化処理が同時に影響している可能性もあります。
- スワップは有効ですか？コンテナやcgroupのメモリ制限はありますか？最近ページ回収（reclaim）が発生しましたか？ ファイルバックマッピングはスワップがなくてもメジャーフォルトを発生させる可能性があります。メモリプレッシャーにより最近ロードされたファイルページが追い出され、フォルトが繰り返し発生することもあります。
- レディネス（readiness）SLOはどの程度ですか？ 10秒以内にトラフィックを受け入れなければならないサービスでは、盲目的に20 GiBをスキャンすることはできません。初期化時間の許容量が長ければ、レディネス前に特定のフォルトを前倒しで処理することが可能です。
30秒の回答フレームワーク
「mmapは20 GiB全体を読み込むことなくファイルバックの仮想領域を作成するため、VIRTは即座に跳ね上がり、RSSは初回アクセス時にのみ増加します。CPUはまずTLBを確認します。エントリが有効かつ常駐していればTLBミスはページテーブルウォークによって解決されますが、ページフォルトはカーネルによる修復を必要とします。LinuxのマイナーフォルトはディスクI/Oを伴いませんが、メジャーフォルトはディスクI/Oを伴うため、コールドなファイルページはページキャッシュが温まるまでメジャーフォルトとリクエストレイテンシを増加させます。読み取り専用ページは8個のワーカー間で共有できるため、RSSの単純合算は重複カウントになります。PSSを使用すべきです。フォルトの増分、RssFile/PSS、読み取りI/O、p99を関連付けて分析した上で、ホットページのみをウォームアップするか、起動時間の許容範囲内でmadviseやMAP_POPULATEを検証します」
このフレームワークは、観測結果を説明し、よくある2つの混同を解消し、測定と判断で締めくくります。完全な回答では、フォルトの処理パスと各最適化手法が機能しない条件についても説明する必要があります。
ステップごとの詳細解説
ステップ1: アドレス空間、マッピング、常駐ページを区別する
仮想メモリは各プロセスに独立したアドレス空間を提供します。仮想アドレスは仮想ページ番号とオフセットで構成されていると見なすことができます。ページテーブルは仮想ページ番号を物理ページフレームにマッピングし、present（存在）、writable（書き込み可能）、executable（実行可能）などの状態やパーミッションを保持します。マルチレベルページテーブルは使用されているアドレス範囲に対してのみ下位レベルを割り当てるため、疎なアドレス空間に対して巨大な線形テーブルを作成することを回避します。
20 GiBのファイルをマッピングした直後の結果は、20 GiBの仮想メモリ領域（VMA）の作成です。このマッピングはそのアドレス範囲がファイルとどのように対応するかを定義するだけであり、カーネルがファイル全体を即座に読み出す必要はありません。その結果、以下の挙動が生じます。
- VIRTまたはVmSizeは一度に約20 GiB増加する。
- アクセスされていないファイルページはRAM上に存在する必要がない。
- クエリが初めてページを読み出すと、カーネルはそのページをページキャッシュにロードし、ページテーブルマッピングを設定する場合がある。
- RSSは常駐している部分のみをカウントするため、ワーキングセットへのアクセスに伴って増加する。
4 KiBのページサイズを前提とすると、20 GiBのマッピング全体にアクセスすることは次のページ数にアクセスすることを意味します。
20 × 2^30 ÷ 4096 = 5,242,880ページ。
この計算は、「すべてをウォームアップする」ことが無償ではない理由を示しています。ごく一部の領域のみがホットである場合、524万を超えるページをスキャンすると価値の低いデータがメモリに持ち込まれ、他の有用なキャッシュエントリが追い出される可能性があります。
ステップ2: TLBとページテーブルの処理フローをたどる
CPUがロード、ストア、または命令フェッチを実行する際、仮想アドレスを変換する必要があります。
- TLBで仮想ページ番号を検索する。
- TLBヒットの場合、物理フレームを取得してオフセットと結合する。
- TLBミスの場合、ハードウェアまたはOSがページテーブルを参照する（ページテーブルウォーク）。
- エントリが有効でパーミッションを満たし、常駐している場合、変換情報をTLBにキャッシュして処理を再試行または継続する。
- 現在のエントリでアクセスを満たせない場合、ページフォルト処理に入る。
TLBミスは「変換キャッシュに存在しなかった」ことを意味します。ページフォルトは「現在のページテーブルの状態ではこのアクセスを完了できない」ことを意味します。前者はページテーブルウォークの追加のみで済む場合があります。後者はカーネル空間に入り、アクセスが正当で修復可能かどうかを判断します。この2つを混同すると、Huge Pages、プリフェッチ、高速ストレージによって何を解決できるかについて誤った判断を下すことになります。
ステップ3: ページフォルトを修復可能と致命的なケースに分類する
ページフォルトは例外（exception）の一種であり、必ずしもプログラムのバグを意味するわけではありません。カーネルはまずアドレスとパーミッションを検証します。
- 正当だが非常駐のファイルページ: ファイルページを読み出すか、既存のページキャッシュページをマッピングする。
- 無名メモリへの正当な初回アクセス: 初回読み取りでは共有ゼロページをマッピングし、初回書き込みでは実際の物理ページを割り当てる。
fork後のプライベートページへの初回書き込み: コピーオンライトを実行し、書き込み元プロセスにプライベートコピーを割り当てる。- 未マッピングのアドレスまたはパーミッション違反: アクセスを修復できない場合、
SIGSEGVなどのシグナルを送信する。
フォルトを修復した後、カーネルはページテーブルを更新し、フォルトを発生させた命令を再試行します。ストレージI/Oが必要な場合、プロセスは待機中にブロックされ、スケジューラが別のタスクを実行する可能性があります。このブロッキング処理こそが、メジャーフォルトがリクエストごとのレイテンシを直接増加させる要因です。
ステップ4: マイナーフォルトとメジャーフォルトを正しく解釈する
Linuxでは、「フォルト処理にディスクI/Oが必要だったか否か」という運用上の違いによって分類されます。
- マイナーフォルト: ディスクI/Oを必要としなかったもの。ファイルページがすでにページキャッシュに存在するものの、当該プロセスにはまだマッピングされていない場合などが該当します。無名メモリがオンデマンドで実体化される場合や、メモリ内でコピーオンライトが完了する場合もこれに含まれます。
- メジャーフォルト: ディスクI/Oを必要としたもの。このシナリオでは、コールドスタート後の最初のクエリがページキャッシュに存在しないインデックスページにアクセスし、カーネルがインデックスファイルからそれを読み出すことを強制される場合に発生します。
以下の2つの反例を挙げると回答の説得力が増します。
- メジャーフォルトはスワップを必須としません。コールドなファイルバックマッピングもストレージI/Oを必要とする場合があります。
- マイナーフォルトはオーバーヘッドがゼロではありません。カーネル空間への移行、ページの割り当て、ページテーブルの更新、命令の再試行が発生します。単に低速なディスクI/Oパスを回避しているだけです。
ステップ5: RSSの単純合算が誤解を招く理由を説明する
8個のワーカーが同じ読み取り専用ファイルマッピングを読み取る場合、対象のファイルページはページキャッシュを介して共有できます。各プロセスのRSSにはそのプロセスにマップされている常駐ページが含まれるため、同じ物理ページが複数のRSS値に現れます。8個すべてのRSS値を合算すると、共有ページが重複してカウントされます。
最低限、以下の項目を区別してください。
VmSize: 仮想アドレス空間のサイズ。VmRSS: このプロセスにおいて常駐しているすべてのページ。RssFile: 常駐しているファイルバックマッピング。RssAnon: 常駐している無名メモリ。PSS: マッピングしているプロセス間で比例配分された共有ページ。VmPTE: ページテーブルエントリによって消費されているメモリ。VmSwap: プロセスのスワップアウトされたプライベート無名データ（ファイルマッピングの全体像ではない）。
/proc/<pid>/smaps_rollupは、プロセス内のすべてのマッピングに関するRSSとPSSの集計値を提供します。8個のワーカーに帰属する物理メモリ使用量を推定する際は、システムのページキャッシュ競合や無関係なプロセスも考慮する必要がありますが、通常はRSSの合計よりもPSSの合計の方が有用です。
ステップ6: 再現可能な観測によってボトルネックを検証する
単一のtopのスクリーンショットから結論を導くのではなく、時系列に沿ったデータを構築します。Linuxテスト環境で以下を収集します。
grep -E 'VmSize|VmRSS|RssAnon|RssFile|VmPTE|VmSwap' /proc/$pid/status
cat /proc/$pid/smaps_rollup
perf stat -e page-faults,minor-faults,major-faults -p "$pid" -- sleep 30次に、まったく同じクエリセットを2回実行します。
- コールドスタート後、リクエストのp50、p95、p99、フォルトの増分、ブロック読み取り数、RSS/PSSを記録する。
- 同一のデータ、並行性、コードパスですぐに再実行する。
- 1回目の実行でメジャーフォルト、読み取りI/O、テールレイテンシがすべて高く、2回目で大幅に低下する場合、オンデマンドでロードされるファイルページが主な要因であるという強力な裏付けになる。
- メジャーフォルトがほとんど発生しないにもかかわらずレイテンシが高い場合は、CPU、ロック、リモート呼び出し、インデックスの内部初期化処理を調査する。
- 制御されたメモリプレッシャー下で再テストし、ホットページの回収によってレイテンシスパイクが再発するかどうかを確認する。
フォルトカウンタは累積値であるため、起動時からの累計ではなく、同一の時間枠内における差分（デルタ）を比較してください。バックグラウンドスキャナーのフォルトがオンラインリクエストによるものと誤認されないよう、ワーカーごとに個別に測定します。
ステップ7: ワーキングセットとSLOに応じた最適化を選択する
最も積極的なアプローチが常に最善とは限りません。
- デマンドページングを維持する: 起動が最も速く、メモリ消費は実際のワーキングセットに比例します。初回アクセスのレイテンシを許容できるワークロードや、ホット領域が頻繁に変動するワークロードに適しています。
- ホットページのみをウォームアップする: レディネス前に代表的なクエリを実行するか、ホットセットマニフェストに基づいてページにアクセスします。限定的なコストを前倒しで支払うアプローチであり、20 GiB全体をスキャンするよりも制御が容易ですが、ホットセットの定義を維持管理する必要があります。
madviseでアクセスヒントを提供する:MADV_WILLNEEDはその範囲が近いうちに必要になることを示し、先読みを可能にします。シーケンシャルパターンとランダムパターンにもそれぞれ専用のヒントが存在します。これらはパフォーマンス向上のためのヒントであり、常駐を保証するものではありません。MAP_POPULATEを検証する: ページテーブルを事前フォルト（prefault）し、ファイルマッピングの先読みを発生させることで、その後のブロッキングフォルトを削減します。トレードオフとして、mmapおよび起動時間の長期化、I/Oとメモリプレッシャーの集中が生じるほか、事前充填が不完全であってもシステムコール自体が失敗するとは限らない点に注意が必要です。- インデックスのレイアウトとワーキングセットサイズを改善する: ホットなメタデータとコールドなデータを分離し、局所性を高め、ページをまたぐランダムアクセスを削減します。これは盲目的なプリフェッチよりも根本的な対策になります。
- トラフィック制御（Traffic Gating）: 定義されたホットセットのカバレッジまたはフォルトレートの目標に達した後にレディ状態とし、ノードが永久にレディにならない状態を防ぐためのタイムアウトを設けます。
Huge PagesはTLBプレッシャーを軽減する可能性がありますが、ファイルI/Oを排除したり、不適切なワーキングセットを是正したりするものではありません。TLBミスが主要なボトルネックであることが証拠によって示され、かつメモリ粒度、断片化、デプロイ環境が許容できる場合にのみ導入を検討してください。
高品質な模範回答
「まず、20 GiBの領域が読み取り専用のファイルマッピングであること、およびmmapがforkの前に実行されていることを確認します。mmapは仮想アドレス範囲とファイルとの対応関係を作成するだけであり、ファイル全体を物理メモリに読み込むわけではありません。そのため、各ワーカーのVmSizeは即座に約20 GiB増加しますが、RSSはクエリがページにアクセスしたときにのみ増加します。
アクセスが発生すると、まずTLBが確認されます。TLBミスは単に直近の変換キャッシュにエントリが存在しないことを意味するだけです。ページテーブルエントリが有効でパーミッションを満たし、物理メモリ上に常駐していれば、ページテーブルウォークとTLBの充填だけで完了し、ページフォルトは発生しません。フォルトは、非常駐のファイルページ、fork後の初回のコピーオンライト書き込み、パーミッション違反など、ページテーブルの状態がアクセスを満たせない場合にのみ発生します。
Linuxのカウンタにおいて、私はマイナーフォルトを『ディスクI/Oを必要としないもの』、メジャーフォルトを『ディスクI/Oを必要とするもの』と定義します。コールドスタート直後は、最初のリクエストで使用されるインデックスページがページキャッシュに存在しない可能性があるため、それらの読み出しによってメジャーフォルトが発生し、テールレイテンシが増加します。同じクエリを繰り返すとページキャッシュにヒットするため、マイナーフォルトのみが発生するか既存のマッピングが使用され、レイテンシは低下します。メジャーフォルトはスワップに限定されるものではなく、スワップのないマシンであってもファイルバックマッピングから発生します。
ワーカー間で読み取り専用ファイルページを共有できますが、各ワーカーのRSSには自身がマップしている共有ページが含まれます。したがって、RSS値を単純に合算すべきではありません。/proc/<pid>/smaps_rollupでPSS、RssFile、RssAnon、VmPTEを確認し、同一の30秒ウィンドウ内でブロック読み取り数、マイナー/メジャーフォルトの増分、リクエストのp99と関連付けて分析します。
検証手順としては、同一のクエリセットを2回実行します。1回目の実行でメジャーフォルト、読み取りI/O、p99が高く、2回目で揃って低下する場合、デマンドロードが主要因である仮説が支持されます。次に、実際のホットなワーキングセットのサイズを測定します。20 GiBのインデックスのうち2 GiBのみがホットである場合、レディネス前にその領域をウォームアップし、シーケンシャルまたはランダムアクセスに応じた適切なmadviseヒントを適用します。SLOでより長い起動コストが許容される場合は、MAP_POPULATEを用いたA/Bテストを実施します。原則としてファイル全体を無条件にスキャンすることはせず、Huge Pagesをページフォルトの万能な解決策として扱うこともしません。最終的な判断は、起動時間、最初の1分間のp99、メジャーフォルト率、PSS、およびメモリ回収後の安定性を比較して下します」
この回答は、概念、観測結果、意思決定をひとつの検証可能な論理チェーンとして結び付けています。面接官がマッピングタイプ、ワーキングセット、レディネスSLOを変更した場合でも、同じフレームワークを用いて妥当な判断を導き出すことができます。
よくある間違い
- VIRTをすでに消費されたRAMとみなす → ファイルマッピングはすべてのページを常駐させることなくアドレス範囲を確保できます → VmSize、RSS、PSS、およびマッピングタイプを総合的に確認する。
- TLBミスをページフォルトと同一視する → 有効で常駐しているページテーブルエントリにはアドレス変換のみが必要です → TLBルックアップ、ページテーブルウォーク、フォルト条件を分けて説明する。
- すべてのページフォルトがディスク読み出しを伴うと主張する → ページキャッシュヒット、無名ゼロページ、コピーオンライトはマイナーフォルトを発生させます → Linuxにおけるマイナー/メジャーのI/O有無による区別を用いる。
- メジャーフォルトはスワップからのみ発生すると主張する → キャッシュされていないファイルバックページもストレージI/Oを必要とします → フォルトが発生したページが無名かファイルバックかを特定する。
- 8個のワーカーすべてのRSSを合算する → 共有ファイルページが重複してカウントされます → PSSを使用して共有ページを比例配分し、RssFileとRssAnonを比較する。
- 起動時からの累積フォルト数を確認する → 特定の低速リクエスト期間との相関を証明できません → 同一インターバル内でのフォルト増分、I/O、レイテンシを比較する。
- 起動時に20 GiB全体をスキャンする → I/Oを浪費し、レディネスを遅らせ、より有用なページを追い出す可能性があります → ホットセットを測定し、SLOで要求される範囲のみをウォームアップする。
MADV_WILLNEEDやMAP_POPULATEが将来のフォルトを完全に排除すると仮定する → 前者はヒントに過ぎず、後者は不完全な場合があり、ページは後から回収される可能性があります → コールドスタート時およびメモリプレッシャー下の挙動をテストする。- 検証なしに即座にHuge Pagesを有効化する → 主に変換カバレッジと割り当て粒度を変更するものであり、ファイルI/Oやワーキングセットの質を改善するものではありません → まずTLBミスが支配的であることを証明する。
フォローアップの質問と回答
フォローアップ1: マシン上にスワップが存在しません。なぜメジャーページフォルトが発生するのですか？
メジャーとは、フォルト処理にディスクI/Oが必要であったことを意味し、その発生元がスワップである必要はありません。このシナリオのインデックスはファイルバックです。ページキャッシュに存在しないファイルページへの初回アクセス時、カーネルはファイルシステムからそれを読み出す必要があるため、メジャーフォルトが発生します。VmSwapのみを確認するのではなく、RssFile、マッピングされたパス、ブロック読み取り数を調査してください。
フォローアップ2: 別のワーカーがすでに同じファイルページを読み込んでいます。このワーカーの初回アクセス時には何が起きますか？
そのページはすでにシステムのページキャッシュに存在している可能性がありますが、このワーカーのページテーブルにはまだマッピングが設定されていません。そのマッピングを確立する処理は通常ディスクI/Oを必要としないため、マイナーフォルトとして現れます。その後のアクセスでは依然としてTLBミスが発生する可能性がありますが、ページテーブルエントリが有効であればページフォルトにはなりません。
フォローアップ3: fork後に少量の書き込みを行うとPSSが増加するのはなぜですか？
プライベートページは初期状態ではコピーオンライトを介して共有されます。初回書き込み時、カーネルは書き込みを行ったワーカーのためにプライベートコピーを作成し、そのページテーブルを更新します。共有されていたページが単一のプロセスに帰属するようになるため、PSSが増加します。このフォルトは通常ディスクI/Oを必要としませんが、メモリ割り当てとコピーのオーバーヘッドが発生します。読み取り専用インデックスでは、プライベートマッピングへの意図しない書き込みを避ける必要があります。
フォローアップ4: アクセスがランダムであるにもかかわらず、サービスがMADV_SEQUENTIALを使用している場合はどうなりますか？
不適切なヒントを設定すると、使用されないページをロードする無駄な先読みが発生し、I/Oが増加します。ランダムなポイントルックアップの場合は、MADV_RANDOMまたはデフォルトポリシーをテストしてください。ホットセットが判明している場合は、対象を絞ったプリフェッチが推奨されます。ヒントの名前だけで判断せず、フォルト数、I/O、PSS、レイテンシに基づいて評価してください。
フォローアップ5: MAP_POPULATEはどのような場合に適していますか？
起動時により多くの時間とI/Oを費やすことが許容され、オンラインでの初回アクセスレイテンシを安定させる必要があり、かつ近いうちに使用されるマッピング範囲が合理的に予測可能な場合に検証する価値があります。マッピングがホットセットよりも大幅に大きい場合、ノードのスケールイン/アウトが頻繁に発生する場合、またはメモリプレッシャーによりページがすぐに回収される環境では無駄になる可能性があります。また、事前充填の失敗が必ずしもmmap自体の失敗を意味するわけではないため、実際の常駐状況とその後のフォルト数を測定する必要があります。
フォローアップ6: ページフォルトの頻発と真のメモリリークをどのように区別しますか？
メモリリークの場合、通常はトラフィックが安定している状態であっても、プライベートな無名メモリや回収不能なオブジェクトが継続的に増加します。ファイルバックのワーキングセットの増加は主にRssFileやページキャッシュに現れ、ページ回収後に減少する可能性があります。RssAnon、RssFile、PSS、VmSwap、およびヒープ/オブジェクトプロファイルを比較した上で、安定したトラフィックおよび制御されたメモリプレッシャー下でテストを繰り返してください。RSSの増加単体では両者を区別できません。