Какие процессы убивает long killer

Процессы, которые "убивает" OOM Killer

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

Критерии выбора "жертвы"

OOM Killer не убивает процессы случайно. Он использует сложный алгоритм, оценивая каждый процесс и присваивая ему "badness score" (oom_score). Чем выше оценка, тем выше вероятность быть завершённым. Эта оценка доступна в /proc/<pid>/oom_score. На неё влияют:

• Объём используемой памяти: Чем больше резидентной памяти (RSS) использует процесс, тем выше его счёт.
• Время работы: Долгоживущие процессы (например, демоны) имеют более высокий приоритет для выживания по сравнению с недавно запущенными.
• Привилегии: Процессы, запущенные от имени root, обычно имеют пониженный счёт (через oom_score_adj или oom_adj), так как их завершение может нарушить работу всей системы.
• Критичность для системы: Процессы, непосредственно отвечающие за работу ядра или жизненно важные подсистемы, защищены.
• Влияние на другие процессы: Процесс, который, будучи убитым, освободит много памяти и, вероятно, позволит выжить многим другим процессам, является идеальным кандидатом.
• Настройки oom_score_adj: Администратор или сам процесс (если имеет права) может явно повлиять на шансы быть убитым, установив значение в файле /proc/<pid>/oom_score_adj в диапазоне от -1000 (никогда не убивать) до +1000 (убивать в первую очередь).

Типичные кандидаты на завершение

Исходя из логики работы, OOM Killer чаще всего выбирает:

1. Пользовательские процессы, потребляющие огромный объём памяти:

    *   Процессы с ошибками (**memory leaks**), которые бесконечно увеличивают своё потребление RAM.
    *   **Научные вычисления**, симуляции, обработка больших данных в памяти (например, неоптимизированные скрипты Python/Pandas, Java-приложения с большими heap-областями).
    *   **Базы данных** (MySQL, PostgreSQL), чей буферный кэш настроен на слишком большой объём памяти.
    *   **Виртуальные машины** и **контейнеры**, особенно если их лимиты памяти не настроены корректно.

1. Процессы с низкой общей "ценностью":

    *   **Недавно запущенные процессы**, которые ещё не выполнили критически важную работу.
    *   **Процессы-потомки (`fork`-процессы)**, которые унаследовали память родителя (особенно актуально в шаблонах `fork()` + `exec()`).
    *   Процессы, запущенные от имени обычных пользователей, а не от **root** или системных служб.

Как проверить и управлять OOM Killer?

Просмотр oom_score для всех процессов:

# Показать PID, имя и oom_score для всех процессов
for pid in $(ps -eo pid); do
    if [ -f /proc/$pid/oom_score ]; then
        echo -n "PID: $pid ($(ps -p $pid -o comm=)) - OOM Score: "
        cat /proc/$pid/oom_score
    fi
done
# Более простая альтернатива (показывает топ потребителей памяти)
ps aux --sort=-%mem | head -20

Защита критического процесса (например, sshd с PID 1234):

# Установить максимальную защиту (никогда не убивать)
echo -1000 > /proc/1234/oom_score_adj

# Или через утилиту choom (из пакета util-linux)
choom -p 1234 -n -1000

Просмотр логов OOM Killer: Сообщения от OOM Killer пишутся в kernel ring buffer. Их можно найти так:

# Просмотр последних сообщений ядра
dmesg -T | grep -i "oom\|killed"

# Поиск в системном журнале (зависит от настройки syslog/rsyslog)
journalctl --since="1 hour ago" | grep -i "out.of.memory\|killed"

Пример записи в логе после срабатывания OOM Killer:

[Wed Oct 26 14:30:15 2023] Out of memory: Killed process 12345 (java) total-vm:10521240kB, anon-rss:8412345kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:21045kB oom_score_adj:0

Профилактика срабатывания OOM Killer

• Адекватный мониторинг памяти с помощью free, vmstat, top.
• Настройка лимитов через cgroups (особенно актуально для контейнеров Docker/Kubernetes):

  # Для Docker
  docker run -m 512m --memory-swap 1g my_app
  

• Оптимизация приложений: Выявление и устранение утечек памяти, настройка оптимальных размеров heap/stack.
• Увеличение swap-пространства (хотя это может привести к swap thrashing и резкому падению производительности).
• Настройка параметров ядра (vm.overcommit_memory, vm.panic_on_oom), но это требует глубокого понимания.

Важный вывод: OOM Killer — это "предохранительный клапан". Его частое срабатывание — это симптом серьёзной проблемы: либо недостатка физической памяти, либо наличия дефектных процессов с утечками. Задача DevOps/SRE — не просто настраивать oom_score_adj, а выявлять корневые причины и устранять их на уровне архитектуры приложения или инфраструктуры.