ゲームラグ白書 › L7 サーバーOS（カーネル）
OOM Killer Out-of-memory killer
原因ID so-oom · 主担当 ゲーム開発チーム・サーバー開発 · 副担当 インフラチーム・サーバーインフラ
図と実験のあるメインページでこのカードを開く →
Linuxはメモリが尽きると、メモリを最も多く使っているプロセスを選んで強制終了します。たいていはゲームサーバーです。
なぜ リークや急増でメモリが枯渇、またはコンテナのメモリ上限に到達 → すると カーネルがゲームサーバーのプロセスを強制終了 → 画面では そのサーバーの全員が同時に切断、直近の進行がロールバックされることもある
- 症状
- 切断, 不発・ロールバック
- 要因
- ストール
- 誰に起きるか
- サーバー全体
- いつ
- 長時間稼働するほど, 人が集中したとき
- 担当
- 主担当 ゲーム開発チーム・サーバー開発 · 副担当 インフラチーム・サーバーインフラ
- ゲーム開発チームの対応
- リークの修正、メモリ使用量に上限を設け、近づいたらデータを保存して正常終了する手順。
- インフラチームの対応
- メモリのアラート、コンテナのメモリ上限を実際の使用量に合わせて設定、先に終了させる順序の調整（oom_score_adj）。
- 数値の目安
- カーネルログ（dmesg）に「Out of memory: Killed process」が残り、KubernetesではOOMKilledと表示されます。WindowsにはOOM Killerがなく、メモリ確保に失敗してサーバーがエラーで落ちることが多いです。
- グラフでは
- 接続が一斉に切れる · 接続数、メモリ使用量
- 確認箇所
- dmesgの「Out of memory: Killed process」の記録、KubernetesならPodステータスのOOMKilled、cgroup v2ならmemory.eventsのoom_killの増加を、接続が切れた時刻と突き合わせて確認
- 該当する場合
- 接続が一斉に切れた時刻にゲームサーバーのプロセスをkillした記録があり、その直前までメモリ使用量が上限に向かって上がっている
- 該当しない場合
- OOMの記録がないのにプロセスが落ちていれば、「サーバークラッシュ」の手順でクラッシュログ・コアダンプを確認
- 確認手段
- インフラのツールで確認（ゲームコード不要）
出典
- mm/oom_kill.c (Linux v6.12) Linux kernel
メモリを最も多く使っているプロセスが最も高いスコアになるよう計算（oom_score_adjを反映）、終了させるときに「Out of memory: Killed process …」を記録 - Assign Memory Resources to Containers and Pods Kubernetes
コンテナがメモリのlimitを超えて使い続けると終了させられ、ステータスがOOMKilledと表示される - Pushing the Limits of Windows: Virtual Memory Microsoft
Windowsではコミット上限に達するとメモリをコミットする確保が失敗し、アプリのエラーやシステム障害につながることがある - Control Group v2 Linux kernel
memory.eventsのoom_kill：このcgroupでOOM Killerがkillしたプロセス数
あわせて読みたい原因
同じ層：L7 サーバーOS（カーネル）
同じ症状（切断）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る