Wiki
Инфраструктура

OOM killer — что это простыми словами

OOM killer (Out-Of-Memory) — механизм Linux-ядра: при нехватке RAM убивает процесс с наибольшим "плохим" score. Причины: swap выключен, лимит cgroup, ленивое OOM.

OOM killer — механизм ядра Linux, срабатывающий, когда системе не хватает памяти и swap нет / исчерпан. Ядро вычисляет oom_score каждого процесса (по размеру + "плохости") и kill -9 самого "жирного". Логи — `dmesg | grep -i oom` или `journalctl -k -g killed`.

Причины: (1) утечка памяти в приложении (JVM, Node без limits), (2) swap выключен (стандарт в облачных VPS), (3) cgroup-лимит превышен (Docker/K8s container memory limit → OOM внутри контейнера), (4) всплеск нагрузки (миллион запросов за минуту → миллион буферов).

Профилактика: (1) monitoring памяти (Prometheus + alert на > 90 %), (2) swap-файл 2 ГБ на VPS — spare-cushion при spike (systemd-swap, sudo dd + swapon), (3) jemalloc/tcmalloc вместо glibc malloc — меньше фрагментации, (4) для JVM — `-Xmx` явно + запас 20 % на metaspace, (5) для Node — `--max-old-space-size=1024`.

У нас на VPS swap выключен по умолчанию (typical cloud practice — swap на NVMe жрёт IOPS). Клиент может включить: `dd if=/dev/zero of=/swapfile bs=1M count=2048 && mkswap /swapfile && swapon /swapfile`.

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

Как защитить конкретный процесс от OOM?
`echo -1000 > /proc/$PID/oom_score_adj` — почти иммунитет. Или systemd unit `OOMScoreAdjust=-1000`.
OOM в контейнере убил всех?
Kernel OOM убивает **только процессы cgroup, где случилось over-limit**, не всех. Логи — `docker inspect $CID` → OOMKilled: true.

Смотрите также