Linux PSI: как диагностировать CPU, memory и I/O pressure на VPS

VPS может выглядеть «не загруженным» по среднему CPU и при этом отвечать рывками: запросы ждут процессор, ядро тратит время на reclaim, а очередь I/O растёт быстрее, чем хранилище успевает её разбирать. Обычные метрики загрузки показывают потребление ресурсов, но не всегда показывают, сколько времени процессы фактически простаивают из-за их нехватки. Linux PSI — Pressure Stall Information — измеряет именно такие задержки для CPU, памяти и I/O. В этой статье разберём, как читать PSI на уровне системы и cgroup v2, как связать его с привычными метриками и как использовать в мониторинге и инцидент-диагностике VPS.

Создайте аккаунт

Быстрая регистрация для доступа к инфраструктуре

Я согласен с политикой обработки данных Зарегистрироваться

Что такое Linux PSI и чем он полезнее одной загрузки CPU

PSI — механизм ядра Linux, который агрегирует время, когда задачи не могут продолжать полезную работу из-за конкуренции за CPU, память или I/O. Интерфейс доступен в /proc/pressure/cpu, /proc/pressure/memory и /proc/pressure/io.

Ключевое отличие PSI от классических метрик в том, что он измеряет не только факт использования ресурса, а потерю времени из-за дефицита ресурса. Поэтому два VPS с одинаковой загрузкой CPU могут иметь совершенно разное качество обслуживания: на одном процессы стабильно получают процессорное время, на другом значительная часть runnable-задач ждёт своей очереди.

Это особенно полезно при коротких всплесках нагрузки. Пятиминутное среднее CPU может выглядеть приемлемо, а latency приложения уже ухудшилась из-за десятков коротких периодов давления.

Для общего мониторинга инфраструктуры PSI хорошо дополняет привычный стек метрик. Если вы ещё не собираете базовые системные показатели, сначала полезно развернуть Prometheus и Grafana для мониторинга серверов, а затем добавить PSI как отдельный слой диагностики.

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

Как читать some, full, avg10, avg60, avg300 и total

Файлы PSI содержат строки some и full. some показывает долю времени, когда хотя бы часть задач была заблокирована ожиданием ресурса. full показывает более тяжёлое состояние: все non-idle задачи одновременно простаивают на данном ресурсе.

some avg10=2.40 avg60=0.85 avg300=0.31 total=18422341
full avg10=0.20 avg60=0.05 avg300=0.01 total=420933

avg10, avg60 и avg300 — скользящие проценты за 10, 60 и 300 секунд. Они удобны для визуальной оценки краткосрочного и устойчивого давления. total — накопленное время stall в микросекундах с момента загрузки, полезное для расчёта собственного rate за произвольный интервал.

Важно учитывать специфику CPU: на системном уровне cpu full семантически не определён и для совместимости ядро выводит ноль. Для CPU основной системный сигнал — some. Для memory и I/O рост full особенно важен, потому что указывает на периоды, когда сервер практически перестаёт выполнять полезную работу.

PSI нельзя интерпретировать через универсальный порог вроде «выше 10% всегда плохо». Допустимый уровень зависит от SLA, типа нагрузки и чувствительности к latency. Сначала соберите baseline на нормальной нагрузке, а затем сравнивайте деградации с этим baseline.

CPU pressure: когда проблема не в среднем utilization

CPU PSI растёт, когда runnable-задачи готовы выполняться, но не получают процессорное время. На VPS это может быть результатом недостаточного числа vCPU, резкого роста параллелизма, слишком агрессивного числа worker-процессов, noisy-neighbor эффекта на уровне виртуализации или ограничений cgroup.

Типичный диагностический набор:

cat /proc/pressure/cpu
uptime
vmstat 1
mpstat -P ALL 1
ps -eo pid,ppid,comm,ni,pri,psr,pcpu --sort=-pcpu | head

Высокий cpu some означает, что часть задач ждёт scheduler. Сопоставляйте его с load average, количеством runnable-задач, per-core utilization и, в виртуальной среде, steal time. Высокий load при низком PSI может быть нормален для I/O-bound нагрузки; высокий PSI при умеренном среднем CPU, напротив, часто указывает на короткие пики или локальную конкуренцию за отдельные CPU.

Практические действия: уменьшить ненужный параллелизм, проверить thread/worker pools, разнести тяжёлые фоновые задания, настроить CPU limits/weights в cgroup либо увеличить число vCPU. Если приложение масштабируется горизонтально, PSI можно использовать как дополнительный сигнал к latency и request queue, но не как единственный autoscaling metric.

Memory pressure: увидеть reclaim и thrashing до OOM

Свободная память сама по себе — плохой индикатор проблемы: Linux активно использует RAM под page cache и освобождает её при необходимости. Настоящая проблема начинается, когда reclaim становится дорогим и процессы регулярно ждут память.

PSI позволяет увидеть эту фазу до того, как сервер дойдёт до OOM killer. Рост memory some означает, что задачи сталкиваются с задержками из-за памяти; рост memory full — значительно более опасный признак, связанный с общей потерей прогресса.

cat /proc/pressure/memory
free -h
vmstat 1
grep -E 'MemAvailable|SwapFree|Dirty|Writeback' /proc/meminfo

Сопоставляйте PSI с si/so в vmstat, page faults, активностью swap, cache hit ratio приложения и latency диска. Если memory PSI устойчиво растёт, причины обычно лежат в одном из четырёх классов: реальный дефицит RAM, утечка памяти, чрезмерный page cache/reclaim или слишком жёсткий лимит cgroup.

Добавление swap не «лечит» нехватку памяти, но может дать системе пространство для менее разрушительного reclaim. Для latency-sensitive сервисов важно проверить реальное влияние swap на отклик. Также полезно ограничивать крупные сервисы через cgroup v2, чтобы один процесс не вытеснял остальные.

I/O pressure: отличить занятый диск от реальных stall

I/O PSI показывает, сколько времени задачи теряют в ожидании операций ввода-вывода. Это более прямой сигнал влияния хранилища на приложение, чем одна только утилизация диска.

cat /proc/pressure/io
iostat -xz 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS

Высокий io some при низком full означает, что часть задач ждёт storage, но система в целом продолжает работать. Рост io full указывает на более серьёзную ситуацию, когда практически вся активная работа зависима от I/O.

Смотрите на PSI вместе с latency, queue depth, IOPS, throughput и типом операций. Насыщение может возникнуть не только из-за «медленного диска»: причиной бывают fsync-heavy workloads, массовая запись логов, database checkpoints, backup, compaction или memory reclaim, который генерирует дополнительный I/O.

Для проектов с интенсивным хранением данных имеет смысл отдельно оценить требования к дисковой подсистеме и архитектуре хранения; базовые сценарии и ограничения VPS описаны в статье о хранении данных на VPS/VDS.

PSI в cgroup v2: найти конкретный сервис, который создаёт давление

Системный PSI отвечает на вопрос «сервер испытывает дефицит ресурса?». Cgroup PSI помогает понять, какой workload его испытывает. В cgroup v2 внутри каждой группы доступны cpu.pressure, memory.pressure и io.pressure с тем же форматом, что и системные файлы.

mount | grep cgroup2
cat /sys/fs/cgroup/system.slice/nginx.service/cpu.pressure
cat /sys/fs/cgroup/system.slice/nginx.service/memory.pressure
cat /sys/fs/cgroup/system.slice/nginx.service/io.pressure

Это особенно полезно на хостах с несколькими сервисами, контейнерами или systemd units. Например, системный memory PSI может быть высоким, но только один batch-worker постоянно находится под reclaim. Тогда правильное решение — не увеличивать RAM всему серверу вслепую, а проверить лимиты и поведение конкретной cgroup.

В глубокой иерархии cgroup учёт PSI имеет накладные расходы. Современный cgroup v2 позволяет отключать PSI accounting на отдельных non-leaf cgroups через cgroup.pressure, если такая оптимизация действительно нужна и вы понимаете последствия.

Если вы используете Kubernetes на VPS, cgroup PSI особенно полезен для расследования resource contention между workloads. Базовую архитектуру кластера можно сверить с нашим руководством по развёртыванию Kubernetes на VPS.

Как собирать PSI в Prometheus и строить алерты

Node Exporter умеет экспортировать pressure-метрики Linux, после чего их можно анализировать в Prometheus как time series. Для production лучше не начинать с жёстких универсальных порогов, а сначала собрать историю по нормальным и проблемным периодам.

Полезный подход к алертингу:

• короткое окно — ловить резкие spikes, которые совпадают с ростом latency;
• среднее окно — отсекать единичные всплески;
• длинное окно — выявлять хронический дефицит ресурса.

Для CPU наблюдайте some; для memory и I/O отдельно отслеживайте some и full. Хороший alert должен включать сопутствующие признаки: request latency, load, swap/reclaim, disk latency, queue depth и состояние приложения.

Например, сама по себе кратковременная memory pressure ещё не означает инцидент. Но memory PSI, который держится выше baseline несколько минут одновременно с ростом p95/p99 latency и swap-in, уже даёт существенно более сильный сигнал.

Если вы строите полноценную observability-систему, PSI хорошо дополняет метрики, логи и трассировки. Подход к такой связке подробно разобран в статье Observability vs Monitoring: Prometheus + Grafana + Loki.

PSI и systemd-oomd: реагировать на memory pressure до системного OOM

systemd-oomd использует данные cgroup v2 и PSI для ранней реакции на memory pressure. Идея в том, чтобы завершить проблемную cgroup до того, как вся система окажется в тяжёлом thrashing или kernel OOM.

Перед включением такой политики важно понимать иерархию сервисов и последствия kill. Нельзя без проверки включать агрессивные значения для критичного stateful-сервиса: database или queue broker может пережить принудительное завершение хуже, чем временный рост latency.

systemctl status systemd-oomd
systemd-analyze cat-config systemd/oomd.conf
systemctl show your-service.service | grep -E 'ManagedOOM|Memory'

Настройку лучше вводить поэтапно: сначала собрать PSI и memory events, определить рабочий baseline, протестировать на staging, затем включить ManagedOOM-политику для перезапускаемых stateless workloads. Для сервисов, которые уже ограничены systemd, полезно одновременно проверить hardening и isolation; отдельные методы описаны в статье про systemd sandboxing.

Практический runbook: что делать при росте PSI на VPS

PSI удобнее всего использовать не как отдельный «красный индикатор», а как первый разворот дерева диагностики.

1. Определите ресурс

for f in /proc/pressure/{cpu,memory,io}; do echo "=== $f ==="; cat "$f"; done

Сравните avg10, avg60 и avg300. Если высокий только avg10 — вероятен кратковременный burst. Если растут все окна, давление устойчивое.

2. Сопоставьте PSI с симптомом приложения

Проверьте p95/p99 latency, error rate, request queue, timeout и throughput. Если PSI растёт без пользовательского эффекта, это может быть допустимый фон. Если корреляция стабильна, PSI становится сильным диагностическим сигналом.

3. Проверьте cgroup

На многосервисном сервере найдите unit/container с максимальным pressure. Не масштабируйте весь VPS до локализации источника.

4. Проверьте вторичные метрики

• CPU: runnable tasks, per-core utilization, steal time, throttling;
• memory: reclaim, swap, faults, memory.current, memory.events;
• I/O: latency, queue depth, IOPS, throughput, fsync/writeback.

5. Исправляйте причину, а не PSI

PSI — измеритель. Для CPU решением может быть меньше конкурирующих workers или больше vCPU; для memory — устранение утечки, изменение cache policy или дополнительная RAM; для I/O — изменение паттерна записи, перенос backup, более быстрый storage или разнос workload.

После изменения сравните PSI и application latency с исходным периодом. Если давление снизилось, а пользовательские метрики не изменились, вероятно, узкое место находилось в другом слое.

Когда PSI действительно стоит включать в production-наблюдение

Linux PSI особенно полезен на VPS, контейнерных хостах и системах с плотной консолидацией, где простого процента CPU или объёма свободной памяти недостаточно. Он показывает не «сколько ресурса занято», а сколько времени workload теряет из-за его нехватки.

Для production минимальный набор выглядит так: системные CPU/memory/I/O PSI, cgroup PSI для критичных сервисов, application latency и базовые вторичные метрики каждого ресурса. Этого достаточно, чтобы быстрее отличить CPU contention от memory reclaim и storage stalls.

Если PSI стабильно коррелирует с деградацией приложения, используйте его для capacity planning и алертинга. Если сервер регулярно упирается в ресурс и оптимизация приложения уже исчерпана, следующий шаг — корректный подбор конфигурации VPS по CPU, RAM и дисковой нагрузке, а не попытка скрыть проблему более агрессивными порогами мониторинга.