TGViewer
SRE | DevOps SRE | DevOps @opennet · 330 subscribers
Post #55 74
PSI (Pressure Stall Information): ранние алерты на деградацию CPU/Memory/IO 🧠

Проблема
Метрики уровня 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
More from @opennet
  1. Apr 29, 2026GitLab Runner autoscaling: устранение задержек старта job (VM executor) Проблема При autos…
  2. Apr 28, 2026Nexus OSS при 500k+ артефактов: тюнинг JVM и blob store Проблема После ~300–500k артефакто…
  3. Apr 27, 2026Golden images для OpenStack: Packer + cloud-init без “снежинок” ⚙️ Проблема Долгая и неста…
  4. Apr 26, 2026Тюнинг sysctl для high-load ingress (10k+ RPS) Проблема На ingress-узлах при 10k+ RPS типи…
  5. Apr 25, 2026OOMKilled в Kubernetes: контроль памяти через cgroup v2 и requests/limits Проблема OOMKill…
  6. Apr 24, 2026Ускорение image pull в Kubernetes через registry mirror + containerd ⚙️ Проблема В кластер…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →