Как Linux выбирает, какой из процессов нужно завершить

Механизм выбора процесса для завершения (OOM Kill) в Linux

В Linux решение о завершении процесса при нехватке памяти принимает Out-Of-Memory (OOM) Killer – компонент ядра, активируемый, когда система исчерпывает физическую память и пространство подкачки. Это крайняя мера для предотвращения полного краха системы.

Как работает OOM Killer

Когда свободной памяти становится критически мало, ядро вызывает OOM Killer. Его алгоритм выбора "жертвы" основан на расчёте "плохости" (badness score) для каждого процесса. Чем выше оценка – тем выше вероятность завершения.

Формула расчёта badness score (упрощённо):

badness_score = memory_usage_in_pages * (memory_usage_in_pages / total_memory) * oom_score_adj

Где:

• memory_usage_in_pages – использование памяти процессом.
• total_memory – общий объём доступной памяти.
• oom_score_adj – настраиваемый коэффициент (от -1000 до 1000), влияющий на приоритет.

Ключевые факторы, влияющие на выбор

OOM Killer стремится завершить процесс, который освободит максимум памяти, нанося минимум вреда системе. Основные критерии:

• Объём используемой памяти: Процессы, потребляющие много RAM, получают высокий балл "плохости".
• Приоритет процесса (oom_score_adj):

    *   Значение `-1000` гарантирует иммунитет (OOM Killer никогда не выберет такой процесс).
    *   Значение `1000` резко увеличивает шансы на завершение.
    *   Обычно системные демоны (например, `sshd`, `systemd`) имеют низкий `oom_score_adj`, а пользовательские приложения – более высокий.

• Время жизни процесса: Долгоживущие процессы (например, демоны) имеют небольшой "бонус" – их ценность для системы считается выше.
• Привилегии: Процессы с правами root или запущенные от имени непривилегированных пользователей? OOM Killer предпочтёт завершить непривилегированный процесс.
• Вклад в общую нагрузку на память: Процессы, активно работающие с памятью (высокий rss – resident set size), являются первыми кандидатами.

Практический пример и управление

Посмотреть текущий oom_score и oom_score_adj можно для любого процесса:

# Найти PID процесса
ps aux | grep myapp

# Посмотреть его текущий oom_score (чем выше, тем вероятнее завершение)
cat /proc/<PID>/oom_score

# Посмотреть и изменить настраиваемый коэффициент oom_score_adj
cat /proc/<PID>/oom_score_adj
echo 200 > /proc/<PID>/oom_score_adj  # Увеличить шансы на OOM kill
echo -500 > /proc/<PID>/oom_score_adj # Уменьшить шансы

Важное замечание: Настройки через /proc – временные. Для постоянного изменения используйте systemd (опция OOMScoreAdjust в юнитах) или настройки приложения.

Современные улучшения

В современных ядрах (примерно с версии 4.19) используется OOM Reaper, который старается завершать процессы более "гуманно", уведомляя их через сигнал SIGTERM перед принудительным SIGKILL. Также появилась политика oom_dump_tasks, позволяющая логировать детальную информацию о всех процессах во время OOM события для последующего анализа.

Стратегии предотвращения OOM Kill

• Мониторинг: Использование инструментов (free, vmstat, prometheus/grafana) для отслеживания использования памяти.
• Настройка swappiness: Оптимизация использования swap-раздела (параметр /proc/sys/vm/swappiness).
• Cgroups / Systemd slices: Ограничение памяти для групп процессов с помощью cgroups v2. Это наиболее эффективный метод в контейнеризированных средах.

  # Пример: ограничение памяти для группы в 500MB
  systemctl set-property myapp.service MemoryMax=500M
  

• Настройка приложений: Корректное ограничение кэшей (например, в базах данных или JVM через -Xmx).

Вывод: Выбор процесса для завершения – это сложный компромисс между объёмом освобождаемой памяти, важностью процесса для работы системы и его настраиваемым приоритетом. Понимание этих механизмов критически важно для DevOps-инженера при диагностике инцидентов, настройке мониторинга и проектировании отказоустойчивых систем.