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

> OOM Killer в Linux завершает процессы при нехватке памяти — разбираем, как найти причину в journalctl, настроить oom_score_adj и добавить swap.

## Что такое 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](https://www.zevshost.net/ru/kb/nastroit-swap-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](https://www.zevshost.net/ru/kb/monitoring-vds/).
- Проверяйте журнал через `journalctl -k` после каждого инцидента — подробнее в статье про [journalctl и rsyslog](https://www.zevshost.net/ru/kb/journalctl-rsyslog-logi/).
- При системной нехватке памяти правильный шаг — увеличить тариф VDS, а не бороться с симптомами.

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

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

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

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

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

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

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

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

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

---

Источник: https://www.zevshost.net/ru/kb/oom-killer-linux/