Linux の OOM Killer を学ぶ ~設計編~

🚨 OOM Killer の優先度をどう決める？

どのプロセスを kill させやすく／kill されにくくすべきかの判断基準まとめ

Linux の OOM Killer（Out-Of-Memory Killer）は、
メモリが枯渇したときに OS を守るためにプロセスを強制終了する仕組みです。

↓前回の記事

しかし、すべてのプロセスが同じ優先度で kill されるわけではありません。 本番運用では **「どのプロセスを守り、どれを犠牲にするか」** を明確にする必要があります。

この記事では、以下を体系的にまとめます：

• OOM Killer の kill 優先度の考え方

• kill されてはいけないプロセス

• kill されてもよい／されるべきプロセス

• 実務で使える判断フロー

• systemd / Docker での設定例

🟥 大前提：OOM Killer は「OS を守るための最後の砦」

OOM Killer の目的は OS 全体のフリーズを防ぐこと。

そのため、
**「落ちて困るプロセス」と「落ちても復旧できるプロセス」 **
を分類することが本質になります。

🟧 kill されてはいけないプロセス（oom_score_adj = -1000）

1. OS の根幹プロセス

• systemd

• journald

• sshd

• kernel threads

これらが kill されると OS が死ぬ。

2. 重要ミドルウェアの master / parent プロセス

• nginx master

• PostgreSQL postmaster

• Redis master

• MySQL / MariaDB mysqld（親プロセス）

• Apache httpd parent

master が死ぬと worker が全滅するため絶対に守るべき

3. Stateful なサービス

• データベース（PostgreSQL / MySQL / MariaDB）

• メッセージキュー（RabbitMQ / Kafka）

• キャッシュ（Redis）

• ストレージ系（Ceph / GlusterFS）

データ破損のリスクがあるため kill されるべきではない。

🟨 kill されても問題ないプロセス（worker / stateless）

1. Web アプリの worker

• Gunicorn worker

• uWSGI worker

• Node.js worker

• PHP-FPM worker

worker は stateless なので、落ちても master が再生成できる。

2. バッチ処理・ジョブキューの worker

• Celery worker

• Sidekiq

• Laravel Queue Worker

落ちても再実行できるなら問題なし。

🟩 優先的に kill されるべきプロセス（oom_score_adj = +1000）

1. メモリリークしやすいアプリ

• Python の無限リスト追加

• Node.js の巨大オブジェクト保持

• Java のヒープリーク

• C/C++ の malloc/free 漏れ

リークが疑われるプロセスは 積極的に kill されるべき

2. 実験的・一時的なプロセス

• python test.py

• node debug.js

• bash infinite.sh

ユーザが試験的に動かしているプロセスは kill されても問題ない。

3. コンテナ内のプロセス（ホストを守るため）

Docker コンテナは cgroup で隔離されているため、
コンテナ内のプロセスが kill されてもホストは守られる。

🟦 実務で使える「OOM 優先度判断フロー」

以下のフローで kill 優先度を決めると失敗しない。

🔥 Step1：Stateful か？

• Yes → kill されてはいけない

• No → Step2

🔥 Step2：master / parent プロセスか？

• Yes → kill されてはいけない

• No → Step3

🔥 Step3：worker / child か？

• Yes → kill されても master が再生成できる

• No → Step4

🔥 Step4：リークしやすい or 実験的か？
Yes → 優先的に kill されるべき

No → 通常扱い

🟪 具体例で比較

プロセス	重要度	kill されるべき？	理由
systemd	Critical	❌	OS が死ぬ
sshd	Critical	❌	SSH ログイン不能
nginx master	Critical	❌	全 worker が死ぬ
nginx worker	Medium	⭕	master が再生成
PostgreSQL postmaster	Critical	❌	DB 全停止
Celery worker	Low	⭕	再実行可能
Python のリークプロセス	Lowest	⭕⭕⭕	OS を守るため

🟫 systemd での OOM 優先度設定

kill されにくくする（重要プロセス保護）

コード

[Service]
OOMScoreAdjust=-1000

kill されやすくする（リークしやすい worker）

コード

[Service]
OOMScoreAdjust=1000

🟦 Docker での OOM 制御

メモリ制限を設定（推奨）

コード

docker run --memory=512m --memory-swap=512m ...

コンテナ内の OOM kill を無効化（ホストは守られる）

コード

docker run --oom-kill-disable ...

🧠 まとめ

種類	kill されるべき？	理由
OS の根幹プロセス	❌	OS が死ぬ
DB / MQ / Redis	❌	データ破損
Web サーバ master	❌	全 worker が死ぬ
Web worker	⭕	再生成可能
バッチ worker	⭕	再実行可能
実験的プロセス	⭕	影響が小さい
メモリリークプロセス	⭕⭕⭕	OS を守るため