MENU

LinuxのOOM Killerが発動する条件と回避策【実務での完全理解】

コマンド編
  • URLをコピーしました！

Linuxを運用していると、ある日突然アプリケーションが終了し、 ログを確認すると OOM Killer が動いていた── という経験をした方も多いのではないでしょうか。

OOM Killer は単なる「メモリ不足」ではなく、 Linuxカーネルが最終手段としてプロセスを強制終了する仕組みです。

本記事では、

  • OOM Killer が発動する正確な条件
  • どのプロセスがなぜ殺されるのか
  • 実務での検知方法
  • 再発防止・回避策

を体系的に解説します。

目次

OOM Killerとは何か

OOM（Out Of Memory）Killer は、 システムがメモリをこれ以上確保できなくなった際に、 Linuxカーネルが自動的にプロセスを強制終了する仕組みです。

重要なのは、

  • OOM Killerはエラーではない
  • OSを守るための安全装置

という点です。

OOM Killerが発動する条件

条件① 物理メモリ＋Swapが枯渇

以下の状態になると、OOM Killer の検討フェーズに入ります。

  • 空きメモリがほぼゼロ
  • Swapも使い切っている

確認コマンド

free -h

条件② メモリ割り当て要求に応えられない

プロセスが新たなメモリを要求した際、

  • 物理メモリ不足
  • Swap確保不可
  • 回収できるキャッシュもない

この状態で初めて OOM Killer が発動します。

なぜそのプロセスが殺されるのか

OOM Killer はランダムにプロセスを殺しているわけではありません。

OOMスコア（oom_score）

各プロセスには「殺しやすさ」を示すスコアがあります。

cat /proc/<PID>/oom_score

評価要素

  • 使用メモリ量
  • root権限かどうか
  • 長時間稼働プロセスか
  • oom_score_adj の設定値

→ 「大量にメモリを使っていて、重要度が低い」と判断されたプロセスが優先的に殺されます。

OOM Killerが発動したか確認する方法

① dmesg を確認

dmesg | egrep -i 'oom|killed process'

典型ログ例

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

② /var/log/messages / syslog

grep -i oom /var/log/messages
grep -i killed /var/log/syslog

OOM Killerが引き起こす実害

  • アプリケーションの突然死
  • DBプロセス終了によるサービス停止
  • 再起動ループ
  • 原因不明の障害として扱われがち

特に Java / DB / コンテナ環境では頻出トラブルです。

OOM Killerを回避する実務的対策

対策① Swapを適切に確保する

Swap がゼロ、または極端に少ない構成は危険です。

推奨目安

  • メモリ 8GB 以下：同容量の Swap
  • 16GB 以上：4〜8GB 程度

対策② メモリ使用量を制限する

systemd サービス制限

[Service]
MemoryMax=2G

Docker / コンテナ

  • –memory オプション指定
  • limitを設定しないのはNG

対策③ oom_score_adj を調整する

重要プロセスを守る

echo -1000 > /proc/<PID>/oom_score_adj
  • -1000：ほぼ殺されない
  • +1000：最優先で殺される

DBや基盤プロセスは必須対策です。

対策④ アプリ側のメモリ設計を見直す

  • Javaの -Xmx が物理メモリ超過
  • メモリリーク
  • キャッシュ無制限

→ OSではなくアプリ設計の問題であるケースが多いです。

対策⑤ vm.overcommit 設定の理解

確認

sysctl vm.overcommit_memory

代表値

  • 0：デフォルト（推奨）
  • 1：無制限（OOMリスク増）
  • 2：厳密制御

理由なく 1 にしている環境は要注意です。

OOM Killerを無効化すべきか？

原則 NGです。

  • OSがフリーズする
  • SSH接続不能
  • 復旧が困難

OOM Killer は「最後の命綱」です。 発動しない設計が正解です。

よくある誤解

  • 「CPUが高いからOOM」 → 関係なし
  • 「Swapがあるから安心」 → 不十分な場合あり
  • 「OOMはバグ」 → 正常動作

まとめ

  • OOM Killerはメモリ枯渇時の最終防衛機構
  • 物理メモリ＋Swap不足が直接原因
  • 殺されるプロセスはスコアで決まる
  • Swap・制限・設計の三点で回避可能
  • 無効化ではなく「発動させない設計」が重要

OOM Killer を理解できると、 「突然落ちるLinux障害」への対応力が一段上がります。

あわせて読みたい
OOM Killer詳細｜Linuxメモリ枯渇時の挙動・調査・対処を完全解説 Linuxサーバーで突然プロセスが落ちる／サーバーが不安定になる原因として非常に多いのが OOM Killer（Out Of Memory Killer）です。 本記事では、OOM Killerの仕組み・…
コマンド編
目次