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

Принципы работы OOM Killer в Linux

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

Основные критерии выбора процесса для завершения

OOM Killer не убивает процессы случайно. Он использует сложный алгоритм оценки, который рассчитывает для каждого процесса "badness score" (оценку "плохости") или oom_score. Процесс с наивысшим значением oom_score становится кандидатом на завершение. Этот расчет основывается на нескольких ключевых факторах:

1. Потребление памяти процессом

• Объем памяти: Основной фактор — сколько физической памяти (RSS — Resident Set Size) и swap использует процесс. Чем больше, тем выше oom_score.
• Учет дочерних процессов: Память, занятая всеми дочерними процессами, также учитывается в оценке родительского процесса.

2. Приоритет процесса (oom_score_adj и oom_adj) Это наиболее важный механизм для управления поведением OOM Killer. Администратор или разработчик могут явно указать, какие процессы следует защищать или, наоборот, предлагать для убийства первыми.

• Значения oom_score_adj (современный интерфейс) и oom_adj (устаревший) задаются в диапазоне от -1000 до +1000 и напрямую влияют на итоговый oom_score.
• -1000: Гарантирует, что процесс НЕ БУДЕТ выбран OOM Killer (например, для критичных системных демонов).
• +1000: Гарантирует, что процесс БУДЕТ выбран первым, если возможно.
• Значение по умолчанию — 0.

Настройка осуществляется через файл в /proc для каждого процесса:

# Чтобы защитить критический процесс (например, SSH-сервер):
echo -1000 > /proc/$(pidof sshd)/oom_score_adj

# Чтобы сделать какой-то процесс "кандидатом номер один":
echo 1000 > /proc/$(pidof some_test_process)/oom_score_adj

3. Время работы процесса и его роль

• Длительно работающие процессы ("старые") получают небольшой "бонус" (уменьшение oom_score). Ядро старается не убивать давно работающие службы, так как их потеря может быть более критичной для системы.
• Привилегии: Процессы с корневыми (root) привилегиями также имеют небольшую защиту (их oom_score немного уменьшается), хотя это не главный фактор.

4. Особенности работы процесса

• Процессы, которые зависли (не выполняют полезной работы) или находятся в состоянии "D" (Uninterruptible Sleep), могут быть оценены выше, так как их завершение потенциально менее вредно.
• Процессы, выполняющие важные I/O операции, теоретически имеют меньший шанс быть убитыми, но это слабо выраженный фактор в текущих версиях ядра.

Как просмотреть текущие оценки OOM?

Администратор может проверить текущий oom_score для процессов:

# Показать oom_score для всех процессов (пример вывода):
ps -eo pid,comm,oom_score | sort -k3 -rn | head -20

# Или посмотреть напрямую через /proc:
cat /proc/$(pidof my_process)/oom_score

Стратегии и политики OOM Killer

В современных ядрах (с ~ 4.x) доступны разные политики (oom_policy) выбора процесса:

• default / oom_kill_task: Основная политика, описанная выше — убить один процесс с максимальным oom_score.
• panic: Если система достигает OOM, ядро может вызвать panic и полностью перезагрузить систему. Это полезно в высоконагруженных кластерах, где "умирающий" хост должен быть быстро заменен.
• Политика cgroup: В контейнерных средах (Docker, Kubernetes) OOM Killer работает на уровне cgroup. Если контейнер превышает лимиты памяти, убивается процесс внутри этого контейнера, а не на всей системе. Это фундаментально важно для оркестрации и изоляции.

Практические рекомендации для DevOps/SRE

• Настройка oom_score_adj: Обязательно защитите ключевые системные и бизнес-сервисы (базы данных, SSH, мониторинг) через oom_score_adj = -1000.
• Мониторинг: Настройте алерты на события OOM Killer (dmesg | grep -i "out of memory" или journalctl). Убийство процесса — симптом более глубокой проблемы: либо недостаточного объема памяти, либо утечки памяти в одном из приложений.
• В контейнерах: Устанавливайте лимиты памяти (memory_limit) для контейнеров и подов в Kubernetes. Это гарантирует, что OOM событие локализуется в пределах контейнера и не влияет на всю систему или другие сервисы.
• Swap: Наличие swap пространства может отсрочить активацию OOM Killer, но также может привести к серьезным проблемам производительности при активном использовании swap. Решение о его размере и использовании должно быть взвешенным.

Таким образом, OOM Killer — это не произвольный "палач", а сложный механизм сбалансированного выбора, который можно и нужно тонко настраивать для обеспечения стабильности высоконагруженных систем.