OOM_KILLER_INVOKED Linux / DevOps

Анализ причин сбоев Linux OOM Killer: расчет oom_score и oom_score_adj

Обновлено: 21.08.2026

Внезапная остановка критических процессов (PostgreSQL, MySQL, Redis, Java JVM) с кодом завершения 137.
В dmesg фиксируется запись Out of memory: Killed process <PID> (<name>).
Полное исчерпание физической RAM и Swap-пространства.

1. Поиск инцидента OOM Killer в системных логах

dmesg -T | grep -Ei "oom[_-]killer|killed process"
journalctl -k --grep="Out of memory" -n 50

2. Просмотр текущего OOM Score процессов

cat /proc/$PID/oom_score
cat /proc/$PID/oom_score_adj

3. Защита сервисов через Systemd Unit

Для предотвращения убийства СУБД выполните systemctl edit postgresql:

[Service]
OOMScoreAdjust=-900

systemctl daemon-reload && systemctl restart postgresql

4. Защита службы SSHD от OOM (иммунитет)

echo -1000 > /proc/$(pgrep -d' ' sshd | awk '{print $1}')/oom_score_adj

5. Тюнинг overcommit памяти в sysctl

Файл /etc/sysctl.d/99-oom.conf:

vm.overcommit_memory = 2
vm.overcommit_ratio = 80
vm.panic_on_oom = 0

sysctl --system

💡 Практика специалистов: Не устанавливайте vm.overcommit_memory = 2 без достаточного объема Swap-файла (Swap >= 50% RAM), иначе процессы начнут получать ошибку ENOMEM (Cannot allocate memory) задолго до полного заполнения RAM.

Частые вопросы (FAQ)

Что означает OOMScoreAdjust = -1000?

Значение -1000 дает процессу абсолютный иммунитет: OOM Killer никогда не выберет его в качестве жертвы при исчерпании памяти.

Почему ядро убивает не тот процесс, который вызвал утечку?

OOM Killer рассчитывает жертву по формуле объема занимаемой анонимной памяти (RSS) и Swap. Жертвой часто становится самая крупная база данных, а не мелкий скрипт, вызвавший переполнение.