メモリ逼迫と OOM Killer
Pro会員限定上級約40分6レッスン
夜中にワーカーが落ちて自動で再起動していました。free と /proc/meminfo で逼迫を測り、メモリを食うプロセスと OOM Killer の痕跡を突き止めます。oom_score の仕組みを理解し、MemoryHigh・MemorySwapMax でスワップも含めたサービスの上限を設計します。
対象者: プロセスが突然落ちる原因を調べたい方 / Java などメモリを多く使うサービスを運用する方
前提知識: 依存関係・再起動ポリシー・drop-in 修了程度
この教材を終えると、できるようになること
- free -h の available と swap、/proc/meminfo の MemAvailable・SwapFree・Committed_AS から、メモリの逼迫度を判断できるようになる。
- ps aux --sort=-%mem で使用量の多いプロセスを特定し、RSS・VSZ・VmSwap の意味と JVM のヒープとの差を説明できるようになる。
- dmesg -T と journalctl で OOM Killer の記録を見つけ、systemd の再起動回数と結びつけて経緯を説明できるようになる。
- /proc/<PID>/oom_score と oom_score_adj の意味を理解し、PostgreSQL が守られている理由を説明できるようになる。
- RSS と VmSwap から上限の根拠を示し、drop-in で MemoryHigh・MemoryMax・MemorySwapMax を設定して、上限到達が journal に oom-kill として残ることを説明できるようになる。
修了後の姿: 障害の根本原因をログとコマンドで突き止められる、チームに頼られる運用エンジニアへ。
Chapter 1メモリの逼迫を読み、上限を設計する
逼迫を数字で測り、OOM Killer の判断を読み、cgroup で被害を囲い込む。
- available とスワップで逼迫を測るfree が少ないのは普通。見るべきは available約6分（有料会員限定）
- メモリを食っているプロセスを特定する%MEM 順に並べると、犯人は一目で分かる約7分（有料会員限定）
- OOM Killer の痕跡を読む「勝手に再起動した」の裏にあるカーネルの判断約7分（有料会員限定）
- OOM Killer は誰を選ぶか（oom_score）スコアは相対値。大きいプロセスほど狙われ、adj で守ることもできる約7分（有料会員限定）
- スワップも含めて上限を設計する（MemoryHigh・MemorySwapMax）MemoryMax だけでは止まらない。スワップと「手前の上限」まで設計する約8分（有料会員限定）
Chapter 2確認クイズ
メモリの指標と OOM Killer・スワップを含めた上限の理解度をチェック。