# 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/uk/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/uk/kb/monitoring-vds/).
- Перевіряйте журнал через `journalctl -k` після кожного інциденту — детальніше у статті про [journalctl і rsyslog](https://www.zevshost.net/uk/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/uk/kb/oom-killer-linux/