OOM Killer詳細｜Linuxメモリ枯渇時の挙動・調査・対処を完全解説

Linuxサーバーで突然プロセスが落ちる／サーバーが不安定になる原因として非常に多いのが OOM Killer（Out Of Memory Killer）です。

本記事では、OOM Killerの仕組み・発動条件・ログの見方・調査方法・再発防止策を、 現場対応レベルで徹底解説します。

OOM Killerとは何か？

OOM Killerとは、Linuxカーネルがメモリ不足に陥った際に強制的にプロセスを終了させる仕組みです。

Linuxでは「メモリが足りない＝即OS停止」ではなく、

• メモリを最も多く消費している
• 影響が小さいと判断された

プロセスを強制Killしてシステムを守る設計になっています。

OOM Killerが発動する典型的な状況

• メモリ使用率が100%近くまで上昇
• swapも使い切られた
• 大量アクセス・バッチ・メモリリーク
• コンテナやJavaプロセスのメモリ暴走

特にswap無効化されている環境では、OOM発生率が非常に高くなります。

OOM Killer発動時の典型ログ

まず最初に確認すべきログです。

grep -i oom /var/log/messages

典型的なOOMログ例：

Out of memory: Kill process 12345 (java) score 987 or sacrifice child
Killed process 12345 (java) total-vm:2048000kB, anon-rss:1800000kB

このログが出ていれば、OOM Killerが確定原因です。

どのプロセスがKillされるのか？（OOMスコア）

OOM Killerは「OOMスコア」に基づいてKill対象を決定します。

スコア確認方法：

cat /proc/12345/oom_score

スコアが高いほど、Killされやすくなります。

現在のプロセス一覧で確認：

ps aux --sort=-%mem | head

OOM Killerが「重要プロセス」を殺す理由

よくある誤解ですが、OOM Killerは 重要度を理解していません。

以下の条件に合うと、DBやWebサーバーでもKillされます。

• メモリ使用量が多い
• oom_score_adj が低く設定されていない

OOM Killer発動後に必ずやる調査

① メモリ使用状況

free -m

② プロセス別メモリ使用量

ps aux --sort=-%mem | head -20

③ swap使用状況

swapon -s

vmstat 1 5

よくあるOOM発生パターン

• Javaアプリのヒープ設定過大
• ログローテート不備による肥大化
• 一時ファイル作成処理の暴走
• コンテナのメモリ制限未設定

OOM Killerを抑制・制御する方法

① swapを適切に設定する

fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

② oom_score_adj を調整する

重要プロセスをKillされにくくします。

echo -1000 > /proc/12345/oom_score_adj

※ -1000 はほぼKill不可

③ systemdサービスでの設定例

[Service]
OOMScoreAdjust=-1000

OOM Killerを無効化してよいのか？

結論：非推奨です。

OOM Killerを無効化すると、メモリ枯渇時に サーバー全体がハングするリスクがあります。

制御はしても、完全無効化は避けましょう。

再発防止の実務ポイント

• メモリ使用率の常時監視
• アプリごとの上限設定
• swapの適切な確保
• 定期的なプロセス棚卸し

まとめ

OOM KillerはLinuxを守る最後の砦です。

重要なのは、

• 発動ログを正しく読む
• どのプロセスが原因か特定する
• 再発しない設計に直す

OOMは「事故」ではなく「設計不足のサイン」です。 本記事を使って、必ず根本対応まで行いましょう。