Сервер тормозит без OOM: как проверить давление памяти через PSI

Свободной памяти мало, но это обычное состояние Linux с файловым кэшем. Сам по себе такой снимок не объясняет, почему обработка очереди стала медленной. Для решения нужен другой вопрос: теряют ли процессы время из-за необходимости освобождать память? На него помогают ответить показатели PSI — Pressure Stall Information.

Посмотреть время ожидания

cat /proc/pressure/memory
cat /proc/meminfo
vmstat 1 10

Первая команда возвращает строки some и full с окнами avg10, avg60, avg300 и накопленным total. some относится к времени, когда хотя бы часть задач простаивала из-за памяти; full — когда одновременно простаивали все задачи соответствующего набора, которые должны были выполнять работу. Значения avg — доли времени в процентах за окна, total выражен в микросекундах. Подробный формат есть в описании PSI ядра.

Не переносите на PSI порог от загрузки CPU. Два процента full для интерактивного сервиса могут быть существеннее двадцати процентов some у фонового расчёта. Сначала найдите связь с задержкой именно вашей работы. Снимайте значение во время проблемы, а не после завершения тяжёлого задания.

Сравнить интервалы, а не накопленные числа

total растёт с момента жизни объекта учёта. Большое абсолютное значение на давно работающем сервере не говорит о текущей аварии. Если за 30 секунд some total увеличился на 3 000 000 микросекунд, доля интервала составила 10%. Для сравнения с прошлой неделей используйте одинаковую длительность окна и одинаковую границу измерения.

Первая строка vmstat обычно описывает среднее с запуска; следующие строки относятся к интервалам. Поля si и so помогут заметить обмен со swap. Отсутствие обмена не исключает давление: освобождение файловых страниц тоже требует работы. Сопоставьте PSI, скорость выполнения задания и активную нагрузку, чтобы не принять полезный кэш за проблему.

Найти область ограничения

При наличии cgroup v2 у сервиса может быть собственный memory.pressure. Системный показатель смешивает влияние всех задач, а групповой помогает проверить конкретного потребителя. Путь берите из ControlGroup у systemd, затем читайте файл в соответствующем каталоге /sys/fs/cgroup. Не выводите путь из имени сервиса вручную: в иерархии возможны slices и экранирование.

Если давление есть только у ограниченной группы, сравните её memory.current и memory.high. Повышение лимита может помочь этой группе и одновременно ухудшить ситуацию соседей. Если давление видно по всей системе, начните с числа одновременно выполняемых заданий, размера рабочих наборов и крупных соседних процессов. Уменьшение параллелизма часто даёт проверяемую гипотезу без смены алгоритма приложения.

Проверить решение

После изменения повторите тот же интервал нагрузки. Запишите скорость обработки, задержки и PSI. Снижение давления при падении полезной производительности требует отдельной оценки: сервер мог просто перестать выполнять достаточно работы. Хорошее завершение расследования — найденный баланс ресурсов и повторяемая процедура измерения.

Откройте программу Linux и Bash для DevOps-инженеров: в ней есть диагностика памяти, процессов и журналов учебного сервиса. Эта практика нужна, чтобы после сигнала о замедлении последовательно проверить ресурсную причину и подтвердить результат, а не ограничиться снимком free.

Ещё по теме

• MemoryHigh замедляет сервис: читаем memory.events до аварии
• Память нескольких worker-процессов: почему сумма RSS завышает расход