OOM Killerとメモリ過剰コミットの設計

なぜメモリを「過剰に約束」するのか

malloc や mmap が成功して返っても、その時点で物理メモリが確保されたわけではありません。Linux はアドレス空間に 仮想的な予約 を与えるだけで、実際の物理ページは最初にそのアドレスへ書き込んだ瞬間のページフォルトで初めて割り当てられます。この遅延割り当ての仕組みは デマンドページングとページフォルト処理 の通りです。

ここで設計上の判断が生じます。確保要求の合計が物理メモリ＋スワップを超えてもよいか という問題です。Linux は既定で「超えてよい」とします。これが メモリオーバーコミット（過剰コミット） です。

賭けである以上、外れることがあります。多くのプロセスが約束した分を一斉に書き込み始めると、遅延割り当てが連鎖し、物理メモリとスワップが本当に底をつきます。確保（約束）の時点では足りていたのに、書き込み（実体化）の時点で足りなくなる ——この時間差こそが過剰コミットの核心であり、後述の OOM Killer が必要になる理由です。

overcommit_memory：約束の会計方針

どこまで約束を許すかは vm.overcommit_memory で切り替えます。これは「確保要求を会計上どう扱うか」の方針であって、実メモリの逼迫時の挙動（OOM Killer）とは別レイヤである点に注意してください。

値 2 の上限は CommitLimit = スワップ総量 + 物理メモリ × overcommit_ratio / 100（あるいは overcommit_kbytes の絶対値指定）で決まります。現在の約束済み総量は /proc/meminfo の Committed_AS で確認できます。

メモリ逼迫時のリクレイム経路

物理メモリが減ってくると、OS はいきなりプロセスを殺すのではなく、まず リクレイム（回収） で空きを作ろうとします。OOM Killer はこの回収が破綻したときの最終手段です。経路を順に追います。

メモリ確保要求（ページフォルトやカーネル確保）:
  空きページがウォーターマーク以上 → そのまま割り当て
  空きが low ウォーターマーク未満:
    1. 非同期回収: kswapd を起こし、背後で回収させる
    2. 同期回収（direct reclaim）: 確保しようとした側自身が回収に従事
         - クリーンなファイルキャッシュページ → 即破棄して回収
         - ダーティページ           → 書き戻してから回収
         - 無名ページ（ヒープ等）    → スワップへ追い出して回収
    3. 回収しても min ウォーターマークを割る → OOM Killer 起動

回収対象の選別、すなわち「どのページを追い出すか」は ページ置換アルゴリズム（LRU・Clock・WSClock） のロジックそのものです。Linux は active／inactive の LRU リストでホット／コールドを判定します。ここで効くのが ページの素性 です。ファイル由来のクリーンなページは捨てるだけで回収できますが、書き換え済みのダーティページは ページキャッシュとライトバックの仕組み の通り書き戻しが先に必要で、回収コストが高くなります。

OOM Killer：誰を犠牲にするか

回収が破綻し、確保要求を満たせないと判断されると OOM Killer が起動します。その仕事は「最小の犠牲で最大のメモリを取り戻す」プロセス選定です。判断基準が OOMスコア（oom_score） です。

スコアの本質は単純で、そのプロセスがどれだけメモリを使っているか（おおむね物理メモリ＋スワップの使用量に比例）が土台になります。たくさん使っているプロセスを殺すほど多く回収でき、かつ「暴走して食い潰した犯人」である確率が高い、という発想です。各プロセスの現在値は /proc/<pid>/oom_score で読めます。

この生スコアを人間／運用の意図で上下させるのが oom_score_adj です。

選定ロジックは「oom_score が最大のプロセスを殺す」が基本ですが、いくつか重要な補正があります。

• oom_score_adj = -1000 は完全保護：監視デーモンや SSH など「これが死ぬと復旧不能」なプロセスを守るのに使います。ただし保護されたプロセスばかりが残ると、回収しきれず最終的に カーネルパニック に至る場合があります。
• 犠牲の波及：選ばれたプロセスを殺すとき、同じスレッドグループは巻き込まれます。狙いは「メモリを丸ごと解放できる単位」を殺すことだからです。
• init（PID 1）等は対象外：これを殺すとシステムが終了するため、選定から除かれます。

cgroup によるOOMの局所化

ここまではシステム全体（グローバル）の逼迫でしたが、現代のサーバーでは cgroup v2 によってメモリ逼迫を プロセス群単位 に閉じ込めるのが実務の主流です。

memory.max を設定したグループは、その上限を超えてメモリを使えません。グループ内の合計使用量が memory.max に達すると、まず そのグループ内だけで リクレイムが走り、回収しきれなければ そのグループ内のプロセスだけを対象に OOM Killer（cgroup OOM）が起動します。システム全体にはまだ空きがあっても、上限を超えたグループの中で犠牲が選ばれる——これが 局所化 の利点です。

cgroup OOM の挙動は、グローバル OOM と同じく「グループ内で oom_score が最大のプロセスを殺す」です。つまり過剰コミット・リクレイム・OOM 選定という三層の仕組みが、グローバルとグループの両スコープで相似形に働きます。コンテナで「ノード全体には余裕があるのに特定 Pod だけ繰り返し OOMKilled される」のは、まさにこの局所化が正しく働いている証拠です。

まとめ

• 過剰コミット は、確保（約束）と書き込み（実体化）の時間差を利用し、物理メモリ＋スワップより多くを約束してメモリ利用率を上げる設計。vm.overcommit_memory の 0（ヒューリスティック）／1（常に許可）／2（厳格会計）で方針が変わり、2 は安全だが空きを遊ばせやすい。
• 実メモリが逼迫すると、いきなり殺さず リクレイム で回収を試みる。クリーンなファイルキャッシュは破棄、ダーティページは書き戻し、無名ページはスワップへ。スワップ無効環境では逃げ道が狭く OOM に直結しやすい。
• 回収が破綻すると OOM Killer が oom_score（メモリ使用量主体）最大のプロセスを殺す。oom_score_adj で保護（-1000）や生贄化（+1000）を明示できる。
• cgroup v2 の memory.max は逼迫とOOMをプロセス群単位に局所化し、memory.high のスロットリングと二段構えで暴走を封じ込める。

土台となる遅延割り当ては デマンドページングとページフォルト処理 と 仮想記憶（ページング）、回収側の選別ロジックは ページ置換アルゴリズム（LRU・Clock・WSClock） も合わせて読むと、メモリ逼迫時の挙動が一本の線で繋がります。