OOM Killer в Linux: почему процесс убит и как это остановить

Что такое OOM Killer и когда он срабатывает

OOM Killer (Out Of Memory Killer) — механизм ядра Linux, который принудительно завершает процессы, когда оперативная память и swap заканчиваются одновременно. Ядро не может позволить системе зависнуть из-за нехватки памяти, поэтому выбирает "жертву" и убивает её сигналом SIGKILL. Чаще всего это происходит на VDS с 1-2 ГБ RAM без настроенного swap, когда MySQL, PHP-FPM или Java-приложение резко увеличивают потребление памяти.

Важно понимать: OOM Killer — это защитный механизм, а не баг. Если он сработал, системе реально не хватило памяти, и причину нужно искать в конфигурации сервисов или в объёме RAM.

Как узнать, что процесс убил именно OOM Killer

Если сервис неожиданно упал без явной ошибки в своём логе, проверьте системный журнал:

journalctl -k | grep -i "out of memory"
dmesg | grep -i oom

В выводе будет запись вида Out of memory: Killed process 1234 (mysqld) с указанием PID, имени процесса и количества занятой памяти на момент убийства. Так проще всего отличить OOM Killer от падения процесса по другой причине — например, ошибки сегментации.

Как найти процесс, который съедает память

Прежде чем настраивать защиту, найдите реального потребителя памяти. Быстрый способ — отсортировать процессы по использованию RAM:

ps aux --sort=-%mem | head -n 10
free -h

Команда free -h покажет общий объём памяти, занятую, свободную и размер swap. Без swap или при малом его размере любой скачок нагрузки — резервное копирование базы, всплеск трафика — мгновенно приводит к OOM. Подробно про настройку подкачки смотрите в статье про swap на VPS Linux.

Как ядро выбирает жертву: oom_score

Каждому процессу ядро присваивает значение oom_score — чем оно выше, тем вероятнее процесс убьют первым. Посмотреть текущий счёт можно так:

cat /proc/PID/oom_score

На счёт влияют объём занятой памяти, время работы процесса и явная настройка oom_score_adj, принимающая значения от -1000 до 1000. Значение -1000 полностью исключает процесс из кандидатов на убийство, а 1000 делает его первой мишенью.

Как защитить важный процесс от OOM Killer

Если на сервере есть сервис, который недопустимо убивать ни при каких условиях — скажем, основная база данных — понизьте его приоритет на убийство:

echo -900 > /proc/$(pidof mysqld)/oom_score_adj

Изменение действует только до перезапуска процесса. Чтобы закрепить настройку постоянно, добавьте параметр в unit-файл systemd сервиса:

[Service]
OOMScoreAdjust=-900

После правки выполните systemctl daemon-reload и перезапустите сервис. Защищая один процесс, вы автоматически повышаете риск для остальных — ядро всё равно найдёт, кого убить, при реальной нехватке памяти.

Профилактика: swap, лимиты памяти и мониторинг

Разовая настройка oom_score_adj не решает нехватку памяти — она лишь перекладывает риск на другой процесс. Реальная профилактика такая:

Настройте swap-файл хотя бы 1-2 ГБ, чтобы сгладить кратковременные пики нагрузки.
Ограничьте память тяжёлых сервисов явно: memory_limit в PHP, innodb_buffer_pool_size в MySQL, -Xmx в Java.
Подключите мониторинг использования RAM, чтобы видеть рост потребления до срабатывания OOM — см. статью про мониторинг ресурсов VDS.
Проверяйте журнал через journalctl -k после каждого инцидента — подробнее в статье про journalctl и rsyslog.
При системной нехватке памяти правильный шаг — увеличить тариф VDS, а не бороться с симптомами.

Частые вопросы

Может ли OOM Killer сработать, даже если на сервере настроен swap?

Да, swap лишь отодвигает момент срабатывания, а не отменяет его: если нагрузка растёт быстрее, чем система успевает выгружать страницы в подкачку, или swap слишком маленький для реального пика потребления, память всё равно закончится и ядро всё равно выберет жертву. Swap снижает частоту таких случаев, но не превращает сервер в защищённый от нехватки памяти.

Если понизить oom_score_adj процесса до -1000, гарантирует ли это, что его никогда не убьют?

Значение -1000 действительно полностью исключает процесс из кандидатов на завершение по правилам oom_score, так что сам он убит не будет. Но это не решает нехватку памяти как таковую: ядро всё равно найдёт другую жертву среди оставшихся процессов, а при полном исчерпании и памяти, и swap система может повести себя непредсказуемо в целом.

Стоит ли просто отключить OOM Killer, чтобы он вообще не трогал процессы?

Нет, это защитный механизм, а не поломка: без него при реальном исчерпании памяти система не падает аккуратно, а зависает целиком, и восстановить её можно будет только перезагрузкой вручную. Правильный путь — не отключать OOM Killer, а убрать саму причину нехватки памяти: добавить swap, задать явные лимиты тяжёлым сервисам и при системной нехватке повысить тариф сервера.

По каким признакам понятно, что серверу пора повышать тариф, а не точечно защищать отдельные процессы?

Если после добавления swap, настройки лимитов памяти сервисов и мониторинга OOM Killer всё равно срабатывает регулярно, а не разово из-за случайного всплеска нагрузки, — это значит, что реального объёма памяти системно не хватает для текущей нагрузки. Точечная защита одного процесса в такой ситуации лишь перекладывает риск на другие сервисы, а не устраняет саму нехватку.