Post #55
74
PSI (Pressure Stall Information): ранние алерты на деградацию CPU/Memory/IO 🧠
Проблема
Метрики уровня
Решение
Использовать PSI (Linux ≥4.20, в проде обычно ≥5.x): метрики давления по CPU/Memory/IO (
---
Практика
Включение в node-exporter (≥1.3 уже умеет PSI):
Проверка:
Пример алерта (Prometheus):
>
---
Как это работает
Ядро считает долю времени, когда задачи не могут выполняться из-за нехватки ресурса.
*
* CPU PSI отражает scheduler contention, memory — давление (reclaim/compaction), IO — ожидание диска.
В отличие от “процентов”, PSI показывает фактическую потерю прогресса.
---
Нюансы
* Пороги зависят от профиля: для latency-чувствительных сервисов
* Смотрите вместе с метриками:
* Memory PSI +
* CPU PSI +
* IO PSI +
* В cgroup v2 можно читать PSI по конкретным группам (
* Краткие всплески нормальны — используйте
---
Когда применять
✔️ multi-tenant кластеры
✔️ high-load ingress/DB/queue
✔️ раннее обнаружение деградации до OOM/timeout
Когда мало пользы
✖️ стабильные, низконагруженные системы
✖️ отсутствие реакции (если нечем масштабироваться/тюнить)
Практический эффект: PSI позволяет поднять алерты за минуты до OOM и латентностных сбоев — давая время на autoscale, перераспределение или троттлинг.
Проблема
Метрики уровня
CPU%/memory usage запаздывают: под уже “плохой”, когда вы видите пик. OOM и latency-спайки возникают раньше — в момент stall’ов (когда процессы ждут ресурсы). Нужен сигнал, который ловит деградацию до аварии.Решение
Использовать PSI (Linux ≥4.20, в проде обычно ≥5.x): метрики давления по CPU/Memory/IO (
/proc/pressure/*). Алертить по some/full avg10 — короткому окну, чувствительному к пикам. В Kubernetes — собирать через node-exporter (включённый collector pressure) или textfile-collector.---
Практика
Включение в node-exporter (≥1.3 уже умеет PSI):
# systemd unit (фрагмент)
ExecStart=/usr/local/bin/node_exporter \
--collector.pressure \
--collector.textfile.directory=/var/lib/node_exporter
Проверка:
curl -s localhost:9100/metrics | grep node_pressure
Пример алерта (Prometheus):
groups:
- name: psi.rules
rules:
- alert: HighMemoryPressure
expr: node_pressure_memory_some_avg10 > 0.2
for: 2m
labels:
severity: warning
annotations:
summary: "Memory pressure on {{ $labels.instance }}"
description: "avg10 > 20%: процессы часто ждут память"
- alert: CPUStallBurst
expr: node_pressure_cpu_some_avg10 > 0.3
for: 1m
labels:
severity: warning
- alert: IOFullStall
expr: node_pressure_io_full_avg10 > 0.05
for: 2m
labels:
severity: critical
>
some — часть задач ждёт ресурс; full — все задачи в группе стоят (сильный сигнал).---
Как это работает
Ядро считает долю времени, когда задачи не могут выполняться из-за нехватки ресурса.
*
avg10/60/300 — скользящие окна (10с/1м/5м).* CPU PSI отражает scheduler contention, memory — давление (reclaim/compaction), IO — ожидание диска.
В отличие от “процентов”, PSI показывает фактическую потерю прогресса.
---
Нюансы
* Пороги зависят от профиля: для latency-чувствительных сервисов
memory some avg10 > 0.1 уже плохо.* Смотрите вместе с метриками:
* Memory PSI +
container_memory_working_set_bytes → близко к OOM* CPU PSI +
container_cpu_cfs_throttled_seconds_total → throttling* IO PSI +
node_disk_* → узкий диск* В cgroup v2 можно читать PSI по конкретным группам (
/sys/fs/cgroup/.../cpu.pressure) — полезно для noisy neighbor.* Краткие всплески нормальны — используйте
for: и avg10, не алертите на avg300.---
Когда применять
✔️ multi-tenant кластеры
✔️ high-load ingress/DB/queue
✔️ раннее обнаружение деградации до OOM/timeout
Когда мало пользы
✖️ стабильные, низконагруженные системы
✖️ отсутствие реакции (если нечем масштабироваться/тюнить)
Практический эффект: PSI позволяет поднять алерты за минуты до OOM и латентностных сбоев — давая время на autoscale, перераспределение или троттлинг.
- ❤ 2