OOM killer Out-of-memory killer

原因 ID so-oom · 主要負責 遊戲開發團隊（伺服器開發） · 協同基礎設施團隊（伺服器基礎設施）

Linux 在記憶體耗盡時，會挑出使用最多記憶體的處理程序強制終止，通常就是遊戲伺服器。

為什麼 洩漏或用量暴增導致記憶體耗盡，或容器達到記憶體上限 → 於是 kernel 強制終止遊戲伺服器處理程序 → 畫面上 該伺服器上的所有人同時斷線，最近的進度可能回檔

症狀: 斷線, 吃指令／回檔
因素: 停滯
誰會遇到: 整個伺服器
何時: 開越久越嚴重, 人潮湧入時
負責單位: 主要負責 遊戲開發團隊（伺服器開發） · 協同基礎設施團隊（伺服器基礎設施）
遊戲開發團隊要做的事: 修正洩漏；設定記憶體用量上限，並建立接近上限時先存檔再正常關閉的流程。
基礎設施團隊要做的事: 設定記憶體警示、依實際用量設定容器記憶體上限、調整優先終止的順序（oom_score_adj）。
數值參考: kernel log（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 增加，與斷線的時間點對照
符合的跡象: 連線同時大量中斷的時間點，有終止遊戲伺服器處理程序的紀錄，而且在那之前記憶體用量一路升到上限
不符合的跡象: 沒有 OOM 紀錄但處理程序死掉時，要查「伺服器當機」的當機 log 與 core dump
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）

出處

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 達到認可限制（commit limit）後，認可記憶體的配置會失敗，可能導致應用程式錯誤或系統故障
Control Group v2 Linux kernel
memory.events 的 oom_kill：這個 cgroup 中被 OOM killer 終止的處理程序數