Архитектура ошибки и симптомы сбоя

Событие «Out of Memory: Kill process (oom_reaper / oom_badness score limit)» не является прямой паникой ядра, но представляет собой критический аварийный инцидент. При полном исчерпании доступной оперативной памяти алгоритм oom_badness() вычисляет процесс с наивысшим баллом потребления ресурсов и отправляет ему сигнал SIGKILL (9). Асинхронный поток oom_reaper мгновенно освобождает структуры памяти убитого процесса.

Диагностическая таблица параметров сбоя

Пошаговое дерево решений и сценарии траблшутинга

Сценарий 1: Защита критического процесса от убийства (1C / PostgreSQL / MySQL)

Установите наивысший приоритет защиты для сервиса через systemd-юнит:

# Внесите правки в юнит (например, /etc/systemd/system/mysqld.service.d/override.conf):
[Service]
OOMScoreAdjust=-1000

# Применение настроек:
sudo systemctl daemon-reload
sudo systemctl restart mysqld

Сценарий 2: Аудит процессов с наивысшим OOM Score

Проверьте текущие баллы всех запущенных процессов в системе:

# Однострочник для вывода ТОП процессов по OOM Score:
printf '%-8s %-6s %-20s %s\n' "PID" "SCORE" "NAME" "COMMAND"
for p in /proc/[0-9]*; do
  pid=$(basename "$p")
  if [ -f "$p/oom_score" ]; then
    score=$(cat "$p/oom_score")
    name=$(cat "$p/comm")
    printf '%-8s %-6s %-20s\n' "$pid" "$score" "$name"
  fi
done | sort -k2 -nr | head -n 15

Сценарий 3: Настройка политики Overcommit Memory

# Запрет чрезмерного перевыделения памяти (для строгих серверов баз данных):
sudo sysctl -w vm.overcommit_memory=2
sudo sysctl -w vm.overcommit_ratio=80