OOM killer

Почему OOM killer существует: переопределение памяти (overcommit).

Linux выделяет память оптимистично. Когда процесс вызывает malloc() или mmap(), ядро предоставляет виртуальное адресное пространство, но не подкрепляет его физической RAM до момента реальной записи (demand paging). Это overcommit: сумма виртуальной памяти всех процессов превышает физическую RAM плюс своп. Работает потому что большинство выделений никогда полностью не используются.

# Проверить политику overcommit:
cat /proc/sys/vm/overcommit_memory
# 0 = эвристика (по умолчанию): разрешать некоторый overcommit
# 1 = всегда разрешать: никогда не отказывать в malloc
# 2 = никогда не превышать: committed <= RAM + swap * ratio

# Текущее состояние:
grep -E 'MemTotal|MemAvailable|CommitLimit|Committed_AS' /proc/meminfo
# MemTotal:       16384000 kB
# MemAvailable:    2048000 kB    ← реально свободно
# CommitLimit:    20971520 kB    ← максимум обещаний (RAM + swap)
# Committed_AS:   18500000 kB    ← сколько уже обещано процессам

# Когда Committed_AS приближается к CommitLimit и страницы реально трогаются,
# ядро исчерпывает физические страницы. Оно должно либо:
# а) Взять страницы из свопа (если своп есть и не исчерпан)
# б) Вызвать OOM killer

oom_score: как ядро выбирает жертву.

У каждого процесса есть oom_score от 0 до 1000. Ядро убивает процесс с наибольшим счётом. Счёт вычисляется из RSS, использования свопа, времени работы и oom_score_adj.

# Прочитать oom_score процесса:
cat /proc/1234/oom_score
# 742   ← высокий: вероятная жертва OOM

# Прочитать oom_score_adj (смещение):
cat /proc/1234/oom_score_adj
# 0     ← смещение не применено (диапазон: -1000 до +1000)

# oom_score_adj = -1000: НИКОГДА не убивать (ядро пропускает)
# oom_score_adj = +1000: убить первым (для пакетных задач)

# Защитить критический процесс (например sshd):
echo -1000 | sudo tee /proc/$(pgrep sshd)/oom_score_adj

# Установить высокий счёт для утилизируемого воркера:
echo 500 | sudo tee /proc/$(pgrep batch-worker)/oom_score_adj

# Постоянно — в unit-файле systemd:
# [Service]
# OOMScoreAdjust=-900   (для критических сервисов вроде БД)
# OOMScoreAdjust=200    (для пакетных задач)

# Сканировать все процессы по oom_score:
for pid in /proc/[0-9]*/oom_score; do
  score=$(cat "$pid" 2>/dev/null)
  comm=$(cat "${pid%oom_score}comm" 2>/dev/null)
  echo "$score $comm"
done | sort -rn | head -10

Чтение события OOM kill в dmesg и journalctl.

# Проверить dmesg на OOM-события:
sudo dmesg | grep -A 20 'Out of memory'
# [123456.789] Out of memory: Killed process 8823 (java) total-vm:4194304kB,
#              anon-rss:3145728kB, file-rss:65536kB, shmem-rss:0kB,
#              UID:1000 pgtables:12288kB oom_score_adj:0

# Расшифровка полей:
# total-vm:4194304kB  = 4 ГБ виртуального адресного пространства
# anon-rss:3145728kB  = 3 ГБ анонимных страниц (куча/стек) в физической RAM
# file-rss:65536kB    = 64 МБ файловых страниц (mmap, разделяемые библиотеки)
# oom_score_adj:0     = смещение не применялось

# В journalctl (journald захватывает сообщения ядра):
sudo journalctl -k | grep -i 'oom\|killed process\|out of memory' | tail -20

# journald также фиксирует unit systemd который был убит:
sudo journalctl -u your-service --since '1 hour ago' | grep -i 'kill\|oom'
# "Memory cgroup out of memory: Killed process ..."  (OOM cgroup)
# или строка ядра выше (системный OOM)

# Полный снимок памяти на момент OOM kill:
sudo dmesg | grep -B 5 -A 50 'Out of memory' | head -80
# Ядро выводит таблицу всех процессов с RSS и oom_score

OOM cgroup против системного OOM: MemoryMax срабатывает первым.

Когда у systemd-сервиса установлен MemoryMax, он получает локальный OOM kill cgroup как только cgroup превышает этот лимит — даже если на хосте гигабайты свободной памяти.

# Различить в логах:
sudo journalctl -k | grep 'oom'
# Системный OOM:
#   "Out of memory: Killed process 8823 (java) score 742..."
#
# OOM cgroup (превышение MemoryMax):
#   "Memory cgroup out of memory: Killed process 8823 (java)..."
#   или (на новых ядрах):
#   "oom-kill:constraint=CONSTRAINT_MEMCG,..."

# Проверить установлен ли MemoryMax:
systemctl show your-service | grep -E 'MemoryMax|MemoryHigh|MemoryCurrent'
# MemoryMax=536870912    ← 512 МБ жёсткий потолок
# MemoryCurrent=498073600  ← сейчас 475 МБ — близко к потолку!

# OOM kill cgroup виден в журнале сервиса:
sudo journalctl -u your-service | grep -i kill

# Настройка: если сервису реально нужно больше памяти — поднять MemoryMax:
sudo systemctl set-property your-service.service MemoryMax=1G

# Если у сервиса утечка памяти — MemoryMax страховочная сетка,
# но реальное исправление — устранить утечку.