Процесс внезапно исчез, сайт упал, а в логах — «Killed»? Скорее всего, сработал OOM Killer (Out Of Memory Killer) — защитный механизм ядра Linux. Когда свободная память заканчивается, ядро не даёт системе полностью зависнуть, а принудительно убивает «самый прожорливый» процесс. Разберём, как найти, что именно упало, кто съел RAM и как настроить сервер, чтобы это не повторялось.
OOM Killer срабатывает при нехватке RAM и убивает процесс с наивысшим oom_score (обычно тот, что занял больше всего памяти). Ищите следы в dmesg/journalctl, а лечение — swap, лимиты памяти или больше RAM на сервере.
Что такое OOM Killer и почему он убивает процессы
Linux позволяет процессам резервировать больше памяти, чем есть физически (overcommit). Пока все не используют её одновременно — всё хорошо. Но когда реальное потребление упирается в предел и swap исчерпан, ядро обязано освободить память немедленно, иначе зависнет вся система. Тогда и приходит OOM Killer: он выбирает процесс с наибольшим «баллом» (oom_score) и завершает его.
Как найти, что именно убили
- dmesg -T | grep -i -E 'killed process|out of memory' — покажет время и имя убитого процесса
- journalctl -k | grep -i 'out of memory' — то же из журнала ядра (с датами)
- Ищите строку вида «Out of memory: Killed process 1234 (mysqld)» — в скобках имя виновника
- grep -i oom /var/log/syslog — на системах, где ядро пишет в syslog
Как найти, кто съедает память
- top или htop → отсортируйте по %MEM (клавиша M в top) — увидите топ потребителей
- ps aux --sort=-%mem | head — топ процессов по памяти списком
- free -h — сколько RAM и swap свободно прямо сейчас
- Проверьте oom_score процесса: cat /proc/<PID>/oom_score — чем выше, тем вероятнее его убьют
Чаще всего OOM ловят MySQL/MariaDB с раздутым буфером, PHP-FPM под нагрузкой, Node.js с утечкой памяти и Java-приложения без ограничения heap. Начинайте расследование с них.
Как не допустить повторения
- Добавьте swap (например файл на 2–4 ГБ) — буфер на пики, чтобы ядро не убивало сразу
- Ограничьте память сервисам: для MySQL — innodb_buffer_pool_size, для PHP-FPM — pm.max_children, для Node — --max-old-space-size
- Используйте systemd-лимиты (MemoryMax=) или cgroups, чтобы один процесс не съел всё
- Настройте мониторинг (free, мониторинг провайдера) и алерты на 80% RAM
- Если памяти стабильно не хватает — апгрейд тарифа VPS под реальные потребности
OOM Killer — это симптом, а не болезнь. Он говорит одно: памяти не хватает. Решение — либо уместить нагрузку в имеющуюся RAM (лимиты, swap), либо дать больше RAM.
Редакция Tophosting
Когда нужен сервер побольше
Swap и лимиты спасают от случайных пиков, но если процессы регулярно упираются в потолок — это сигнал, что тариф маловат. Перенесите проект на VPS с запасом RAM: Vultr, 1Gbits или AdminVPS дают конфигурации от 2 до 16+ ГБ с почасовой оплатой, так что можно поднять память ровно под нагрузку, не переплачивая.
Итог
OOM Killer — не баг, а защита ядра от полного зависания при нехватке памяти. Алгоритм прост: найти убитый процесс в dmesg, определить пожирателя RAM через top/ps, а дальше — swap, лимиты или апгрейд. Если памяти не хватает постоянно, присмотритесь к VPS с большим объёмом — Vultr, 1Gbits или AdminVPS из нашего рейтинга.
