cgroup: memory.high threshold exceeded, paging out processes Linux / DevOps

cgroup: memory.high threshold exceeded — Оптимизация памяти cgroups v2

Обновлено: 18.08.2026 · Официальная база знаний

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

Событие «cgroup: memory.high threshold exceeded, paging out processes» регистрируется подсистемой управления памятью cgroups v2 (Memory Controller). Параметр memory.high выполняет роль «мягкого лимита» (Soft Limit) памяти. При его превышении ядро не убивает процессы через OOM Killer, а начинает агрессивно вытеснять страницы памяти контейнера в Swap (Paging Out / Direct Reclaim) и искусственно задерживает (throttling) системные вызовы выделения памяти для процессов этой cgroup, вызывая лавинообразный рост задержек (Latency Spikes).

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

Параметр	Значение	Инженерный смысл сбоя
memory.high	Soft Limit (bytes)	Порог срабатывания превентивного вытеснения страниц и троттлинга.
memory.max	Hard Limit (bytes)	Жесткий лимит памяти; при его превышении срабатывает Cgroup OOM Killer.
Direct Reclaim	Memory Throttling	Принудительное замедление потоков приложения для очистки Page Cache.

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

Сценарий 1: Проверка текущей утилизации и троттлинга cgroup

# Анализ давления на память cgroups v2 (Pressure Stall Information - PSI):
cat /sys/fs/cgroup/system.slice/service_name.service/memory.pressure

# Просмотр текущей статистики использования памяти cgroup:
cat /sys/fs/cgroup/system.slice/service_name.service/memory.stat
cat /sys/fs/cgroup/system.slice/service_name.service/memory.current

Сценарий 2: Корректировка порогов memory.high и memory.max в Systemd

Увеличьте дистанцию между мягким и жестким лимитом памяти:

# Редактирование параметров сервиса:
sudo systemctl edit service_name.service

# Добавьте в открывшуюся конфигурацию:
[Service]
MemoryHigh=8G
MemoryMax=10G
MemorySwapMax=2G

# Примените конфигурацию:
sudo systemctl daemon-reload

Сценарий 3: Настройка параметров вытеснения в Swap (memory.swap.high)

Если система слишком агрессивно сбрасывает данные на диск, отрегулируйте использование Swap контроллером памяти:

# Ограничение скорости свопинга для cgroup:
echo 1G | sudo tee /sys/fs/cgroup/my_cgroup/memory.swap.high

Приложения в контейнерах тормозят без видимых причин?
ITSTM настроит предиктивный мониторинг метрик PSI (Pressure Stall Information), оптимизирует профили cgroups v2 и исключит скрытый I/O троттлинг памяти.

Практический опыт инженера: При настройке лимитов в cgroups v2 всегда устанавливайте memory.high на уровне 80–85% от memory.max. Это дает ядру временной буфер для мягкого сброса кэшей и предотвращает жесткий OOM Kill контейнера при резких спайках нагрузки.

Частые вопросы (FAQ)

Чем memory.high отличается от старого memory.soft_limit_in_bytes из cgroups v1?

В cgroups v1 мягкий лимит срабатывал только при глобальной нехватке памяти во всей системе. В cgroups v2 механизм memory.high изолирован: он активирует локальный reclaim и троттлинг внутри конкретной cgroup сразу при пересечении порога, защищая остальную систему.

Почему процесс не падает по OOM, но начинает отвечать в 10 раз медленнее?

При превышении memory.high ядро принудительно вставляет задержки (Memory Allocation Delays) в системные вызовы потока, заставляя его тратить процессорное время на очистку Page Cache вместо выполнения полезной работы.

Что показывает метрика memory.pressure (PSI)?

Метрики PSI (some и full) показывают процент времени, в течение которого задачи ожидали освобождения страниц памяти или завершения операций Swap. Значение some > 10% указывает на критическую нехватку RAM.

Как полностью отключить порог memory.high для контейнера?

Запишите значение max в файл конфигурации: echo max | sudo tee /sys/fs/cgroup/my_cgroup/memory.high.