# OOM killer

_Процессы и ресурсы · LinuxLab Knowledge Base_

**TL;DR:** OOM killer - механизм ядра, который выбирает и завершает процесс когда
система упирается в лимит памяти. В контейнерах работает per-cgroup.


## Когда срабатывает

Linux обычно **переподписывается на память** (overcommit) - если все
процессы попросят одновременно всю свою заявленную память, физических
страниц не хватит. Пока никто не пытается активно использовать -
работает. Когда упёрлись:

- на хосте: kernel запускает global OOM killer
- в контейнере / cgroup'е с `memory.max`: запускается **cgroup OOM**,
  убивает только в пределах этого cgroup'а

Альтернатива - общий kernel panic, но это последнее средство.

## Как выбирается жертва

Каждому процессу присваивается `oom_score` (0..1000) на основе:

- **сколько RAM** он съел (главный фактор)
- `oom_score_adj` - ручная корректировка (-1000 = неуязвим, +1000 = убьёт первым)
- root-процессы получают небольшой штраф (минус несколько процентов)

Файлы:

```bash
cat /proc/<pid>/oom_score        # текущий итоговый скор
cat /proc/<pid>/oom_score_adj    # ручная корректировка
```

## Как защитить критический процесс

```bash
echo -1000 | sudo tee /proc/$(pidof sshd)/oom_score_adj
# → теперь sshd никогда не будет жертвой OOM
```

В systemd-юните то же самое через `OOMScoreAdjust=-1000`.

## OOM в [cgroups](/kb/cgroups.md) v2

В v2 опция `memory.oom.group = 1` меняет поведение: при OOM убивает не один
«худший» процесс, а **весь** cgroup. Это критично для приложений где
потеря одного worker'а ломает остальных (Kubernetes use case).

## Признаки что был OOM

```bash
dmesg | grep -i 'killed process'
journalctl -k | grep -i oom
# Mar 14 12:34:56 host kernel: Out of memory: Killed process 1234 (chrome) ...
```

В контейнере `docker inspect` покажет:

```bash
docker inspect <container> --format '{{.State.OOMKilled}}'
# true → контейнер был убит OOM, не сам завершился
```

Главные причины OOM на проде:

1. **Memory leak** в приложении (Java/Node без heap-limit ровно до RAM сервера)
2. **Слишком тесный лимит** в k8s - приложение работает но не помещается
   в лимит на пиках; решает увеличение request/limit или vertical autoscaling
3. **Большой ALLOCATION** одной операцией (читать огромный файл целиком)


## Команды

```bash
cat /proc/$$/oom_score
```
OOM-скор текущего процесса (выше = больше шанс быть убитым)

```bash
echo -500 | sudo tee /proc/$$/oom_score_adj
```
Снизить вероятность что текущий процесс будет жертвой OOM

```bash
dmesg -T | grep -i 'killed process'
```
История OOM-убийств с человекочитаемыми timestamp'ами

```bash
cat /sys/fs/cgroup/memory.events
```
Счётчики low/high/max/oom для текущего cgroup'а

```bash
cat /sys/fs/cgroup/memory.oom.group
```
Если 1 - OOM убивает весь cgroup, не один процесс


## См. также

- [Процесс и PID](/kb/process-and-pid.md)
- [Сигналы (SIGTERM, SIGKILL, SIGHUP)](/kb/signals.md)
- [cgroups (v2)](/kb/cgroups.md)
- [cgroups v2 - unified hierarchy, PSI, eBPF control](/kb/cgroups-v2-deep.md)
- [dmesg - kernel ring buffer](/kb/cmd-dmesg.md)
- [sysctl - крутилки ядра](/kb/cmd-sysctl.md)
- [kubelet - архитектура агента ноды Kubernetes](/kb/kubelet-internals.md)