USE на Linux: CPU, память, диск, сеть и PSI

Webhook-воркер Stripe завис на 11 минут в 2024 году. Дашборды free-RAM показывали достаточно свободной памяти. Реальная причина — memory pressure ядра на уровне 90%: ядро трэшило reclaim. PSI поймал следующий инцидент за 30 секунд. Дашборды free-RAM по-прежнему ничего не показывали.

USE-чек-лист ресурсов для Linux

Оригинальный USE-чек-лист Brendan Gregg для Linux охватывает около 30 ресурсов × 3 ячейки U/S/E. В связке node_exporter + Prometheus ключевые из них:

PSI: Pressure Stall Information

PSI смержен в Linux 4.20 (декабрь 2018) Johannes Weiner из Facebook, устранив давний пробел в наблюдаемости: до PSI saturation приходилось выводить из load average, столбца r vmstat и iowait — ни один из них не масштабируется корректно на много ядер и не фиксирует кратковременное насыщение.

PSI публикует по /proc/pressure/{cpu,memory,io} шестизначный отчёт для каждого ресурса:

some avg10=5.20 avg60=3.11 avg300=1.02 total=1234567
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

• some: хотя бы одна задача была заблокирована ожиданием этого ресурса, усреднено за 10 с / 60 с / 300 с.
• full: все не-idle задачи были заблокированы. Это критический сигнал — если full > 0 для памяти или I/O более 10 секунд, у тебя почти наверняка кризис, даже если free-RAM выглядит нормально (ядро трэшит reclaim).

Накладные расходы PSI: меньше 1% (счётчики на стороне ядра, без per-task трассировки).

node_exporter публикует PSI как node_pressure_cpu_waiting_seconds_total, node_pressure_memory_waiting_seconds_total и node_pressure_io_waiting_seconds_total.

Почему PSI лучше load average

Load average смешивает runnable- и uninterruptible-задачи, странно масштабируется при разном числе ядер и является 1-минутным экспоненциальным скользящим средним — кратковременный CPU-кризис на 5 секунд почти не отражается. На 64-ядерном хосте load average 10 — норма; на 2-ядерном — катастрофа. PSI нормализует по wall-clock времени и не зависит от числа ядер.

Рекомендуемые production-пороги для алертов:

• rate(node_pressure_cpu_waiting_seconds_total[5m]) > 0.1 (10% времени заблокировано на CPU) → warning
• rate(node_pressure_memory_stalled_seconds_total[5m]) > 0 в течение 10 мин → memory crunch, page немедленно
• rate(node_pressure_io_stalled_seconds_total[5m]) > 0 в течение 5 мин → I/O crunch

Kubernetes 1.27+ использует PSI внутри для решений об эвикции по той же причине.

Как выглядят USE-сигналы при сбоях

CPU-bound нагрузка: Utilization приближается к 100%, saturation (длина run-queue) растёт выше числа ядер. Это верный сигнал того, что scale out поможет. CPU на запрос остаётся стабильным — это объём, не регрессия.

Утечка памяти: Utilization растёт медленно, si/so (swap-in / swap-out) в конечном счёте становятся ненулевыми. PSI memory full переходит с 0 в ненулевое — ядро трэшит reclaim для освобождения страниц.

Disk-bound нагрузка: %util близко к 100% на одном или нескольких дисках, глубина очереди растёт, PSI io some увеличивается. Именно это убило воркер Stripe выше — видно в PSI, невидимо в free-RAM.

Network-bound: TCP retransmit растут (node_netstat_Tcp_RetransSegs), NIC-дропы растут, пропускная способность у максимума линка.