OOM Killer завершил процесс: как восстановить сервис и найти причину
Когда системе или cgroup не хватает памяти, kernel может завершить процесс, чтобы вернуть работоспособность. Перезапуск восстанавливает сервис, но без разбора памяти инцидент повторится.
Таймлайн инцидента
Демо показывает разницу между ручной проверкой и автоматическим мониторингом.
Диагностика OOM Killer: kernel log, victim process, cgroup limits, memory leak, swap, PHP/Java/containers и безопасный план исправления.
Подтвердите факт OOM
Проверьте kernel journal/dmesg около времени сбоя: сообщения содержат invoked oom-killer, killed process, объём памяти и контекст. В контейнере дополнительно проверьте OOMKilled и memory limit.
Не путайте OOM с обычным exit, segfault или ручным restart. Точная причина нужна до изменения лимитов.
Восстановите сервис безопасно
Если процесс критичный, восстановите его по runbook и проверьте health endpoint. Не запускайте бесконечный restart loop: он может усилить нагрузку и скрыть данные.
Оцените свободную память, swap, соседние процессы и незавершённые операции. При необходимости временно ограничьте трафик или фоновые задачи.
Мониторинг покажет, когда состояние изменится
Добавьте сайт или сервер один раз — perfMon будет проверять его автоматически, сохранит историю и сообщит о сбое и восстановлении.
Найдите источник роста памяти
Сравните RSS и working set процессов во времени. Причиной бывает утечка, слишком большая очередь, кеш без лимита, крупный batch, PHP-FPM workers или JVM heap плюс off-heap память.
В контейнерах учитывайте memory limit, а не только RAM хоста. Процесс может быть убит внутри cgroup при свободной памяти на сервере.
Предотвратите повторение
Исправьте утечку или ограничьте concurrency/cache. Увеличение RAM или limit оправдано, если workload ожидаемо вырос и приложение эффективно использует память.
Настройте раннее предупреждение по memory pressure, но оставьте запас до OOM. Добавьте событие восстановления и ретроспективу: какой процесс рос, почему порог не сработал и кто владеет исправлением.
Автоматизируйте проверку, описанную в статье
Разовая диагностика помогает сейчас. Регулярный мониторинг нужен, чтобы не пропустить повторение проблемы.
Настроить бесплатноПрименить на практике
Частые вопросы
Короткие ответы на вопросы, которые обычно возникают при диагностике.
OOM Killer всегда убивает самый большой процесс?
Нет. Kernel использует oom score и ограничения, включая cgroup. Жертва выбирается по нескольким факторам.
Достаточно добавить swap?
Swap может дать время и снизить риск мгновенного OOM, но часто увеличивает latency и не исправляет утечку или неверный limit.
Почему контейнер OOMKilled, если на хосте есть RAM?
У контейнера может быть собственный cgroup memory limit. При его превышении процесс завершается независимо от общей свободной памяти хоста.
Не ждите следующего сообщения «сайт не работает»
Добавьте первый сайт или сервер: perfMon будет проверять состояние автоматически, сохранит историю и уведомит ответственных.