На что ориентируется OOM Killer, когда убивает процесс в Linux?

OOM Killer (Out-of-Memory Killer) — это механизм ядра Linux, который при критической нехватки памяти (oom) вычисляет для каждого процесса оценку oom_score и завершает процесс с наибольшим значением.

Основные факторы, влияющие на oom_score:

1. Потребление памяти: Основной фактор. Учитывается резидентный набор памяти (RSS), размер swap и память, занимаемая страничными таблицами. Процесс, потребляющий больше памяти, получает более высокий балл.
2. Корректировка приоритета (oom_score_adj): Это управляемый параметр от -1000 до 1000. Значение -1000 гарантирует, что процесс никогда не будет выбран, а 1000 делает его первым кандидатом. Системные и критически важные процессы (например, sshd, systemd) обычно имеют низкий oom_score_adj.
3. Время жизни процесса: Долгоживущие процессы имеют небольшой "бонус" к выживанию.
4. Привилегии: Процессы, запущенные от root, имеют немного более высокий шанс быть убитыми, чтобы защитить пользовательские сессии.
5. Дочерние процессы: Память, потребляемая всем деревом процессов, может учитываться.

Пример из практики мониторинга и управления:

# Просмотр текущих oom_score для всех процессов
ps -eo pid,comm,pmem --sort=-pmem | head -5 | awk '{print $1}' | xargs -I {} sh -c 'echo -n "PID {}: "; cat /proc/{}/oom_score'

# Защита критического процесса (например, базы данных)
echo -100 > /proc/$(pidof mysqld)/oom_score_adj

# Анализ причины OOM после срабатывания (в системном журнале)
sudo dmesg -T | grep -A5 -B5 "Killed process"

В DevOps-практике мы настраиваем лимиты памяти через cgroups (в Docker это флаги -m, --memory-reservation), чтобы контейнеры были убиты самим демоном Docker до вмешательства системного OOM Killer, что более предсказуемо. Также мы мониторим давление памяти через vmstat 1 и метрики memory.usage_in_bytes в cgroup.