経緯
メモリ枯渇を疑うとき見るべきものについて調査中，journalctl | grep -i "kill" | lessでOOM killerが発生していないか確認するところまでやったが，killされたプロセスがメモリ枯渇の犯人とは限らないのではないかと思ったため下記の質問をした．
質問：「oom_score_adjは多くの場合0なので，killされたプロセスのoom_score_adjが0であれば，そのプロセスのメモリ使用量が大きかったと判断して良い．
逆に，oom_score_adjが2など大きい場合には別に犯人がいる可能性があると考える．
この認識で良いですか？」
以下はChatGPTの回答．
はい、かなり正確な理解です！
以下に、あなたの認識を補足しながら整理していきます。
✅ あなたの認識：ほぼ正しい！
🔹
oom_score_adj == 0のプロセスが kill された場合 →
➤ そのプロセスが相対的にメモリを多く使っていたと考えて良い。
🔹
oom_score_adjが大きい（例：+500や+1000）
➤ そのプロセスは意図的に「殺されやすい」よう調整されている。
➤ 実際に犯人が別にいる（けどそっちは優先度が低くて見逃された）可能性がある。
💡 詳細補足
oom_score
- 0〜1000の値で、実行中プロセスの kill 優先度を示す。
- メモリ消費量（RSSなど）に基づいて自動計算されます。
- このスコアが高いほど kill されやすい。
oom_score_adj
- -1000〜+1000 の手動調整値。
-
/proc/[pid]/oom_score_adjに書き込んで調整できます。 - 実際のスコア計算は以下のように影響を受けます：
effective_score = oom_score + oom_score_adj（※簡略化して言えば）
例：
| プロセス | メモリ使用 | oom_score_adj | 備考 |
|---|---|---|---|
| A | 2.5 GB | 0 | 💀 kill 対象（重い＋調整なし） |
| B | 1.0 GB | +800 | 😱 優先的に kill される（軽いが killしやすい） |
| C | 3.0 GB | -1000 | 🔒 保護対象（いくら重くても kill されない） |
✅ まとめ
| 観点 | 内容 |
|---|---|
oom_score_adj=0 で kill |
おそらくそれが「重い犯人」 |
oom_score_adj>0 で kill |
優先的に kill されただけ。犯人は別にいる可能性あり |
oom_score_adj<0 |
保護対象。ほぼ kill されない |
| 実際の犯人特定には？ |
oom_score_adj と メモリ使用量（VmRSSなど）を両方見ると◎ |
必要なら、oom_score_adj を使って任意のプロセスに「優先度」をつける方法も紹介できます！興味あります？