Проверка процессов с изменённым OOM Score: /proc/*/oom_score_adj

Когда Linux заканчивается память, ядро запускает OOM Killer. Он выбирает процесс для завершения не случайно - решение зависит от внутренней оценки процесса.

Этой оценкой можно управлять через oom_score_adj.

▪️Посмотреть текущий OOM score процесса
У каждого процесса есть файлы в /proc:

cat /proc/$(pidof nginx)/oom_score

И значение корректировки:

cat /proc/$(pidof nginx)/oom_score_adj

oom_score — итоговый рейтинг для OOM Killer.
oom_score_adj — ручная поправка от -1000 до 1000.

▪️Найти процессы с изменённым приоритетом

for f in /proc/[0-9]*/oom_score_adj; do
    value=$(cat "$f" 2>/dev/null)

    if [ "$value" != "0" ]; then
        pid=${f#/proc/}
        pid=${pid%/oom_score_adj}
        echo "$pid: $value"
    fi
done

Если процесс имеет значение отличное от 0, кто-то явно менял его приоритет.

▪️Что означают значения

Например:

-500
Процесс сложнее убить при OOM.
500
Процесс становится более вероятной жертвой.
Особое значение:
-1000
полностью запрещает OOM Killer выбирать этот процесс.

▪️Посмотреть, кто занимает память и имеет высокий приоритет убийства

ps -eo pid,comm,rss,oom_score_adj --sort=-rss | head

Получаем одновременно:

PID;
имя процесса;
потребление памяти;
настройку OOM.

▪️Где это встречается
systemd может задавать параметр прямо в unit:

[Service]
OOMScoreAdjust=-500

Также это часто используют контейнерные системы, чтобы защитить критичные процессы.

▪️Почему это важно

Иногда при расследовании OOM кажется, что ядро “выбрало неправильный процесс”. Но причина может быть в изменённом oom_score_adj.

Аудит этого параметра помогает понять, почему один сервис пережил нехватку памяти, а другой был завершён.

BashTex 📱 #bash #linux