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

Сбой «Kernel panic - not syncing: Out of memory and no killable processes...» возникает, когда подсистема управления виртуальной памятью (VMM) полностью исчерпала физическую RAM и область подкачки (Swap), а стандартный механизм OOM Killer не смог найти ни одного пользовательского процесса, допустимого к завершению (либо все оставшиеся процессы защищены через oom_score_adj=-1000, либо система находится в режиме принудительной паники).

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

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

Сценарий 1: Отключение паники при OOM (возврат стандартного OOM Killer)

Проверьте текущие параметры ядра и верните стандартное поведение:

# Проверка текущих параметров:
sysctl vm.panic_on_oom

# Отключение принудительной паники ядра:
sudo sysctl -w vm.panic_on_oom=0

# Фиксация в /etc/sysctl.d/99-memory.conf:
echo "vm.panic_on_oom = 0" | sudo tee -a /etc/sysctl.d/99-memory.conf
sudo sysctl -p /etc/sysctl.d/99-memory.conf

Сценарий 2: Расширение и настройка файла подкачки (Swap)

Если Swap отсутствует или имеет слишком малый объем:

# Создание Swap-файла размером 8GB
sudo fallocate -l 8G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# Добавление в /etc/fstab для автозагрузки
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Сценарий 3: Настройка резервирования памяти и лимитов cgroups

• Для серверов баз данных (PostgreSQL/MySQL) настройте vm.min_free_kbytes, чтобы ядро всегда сохраняло пул памяти для сетевых буферов.
• Ограничивайте память контейнеров Docker/Kubernetes через memory.max, чтобы утечки в микросервисах не роняли хостовую ОС.