В прошлом уроке мы говорили про логи и первый взгляд на систему. Сегодня - про то, как вообще НЕ паниковать. Методология - это просто заранее заготовленный маршрут, по которому ты идёшь, когда всё горит. Чтобы анализ производительности Linux был не лотереей, а предсказуемой процедурой: пришёл, проверил по списку, нашёл узкое место. Хороший метод экономит не минуты, а часы - потому что не даёт тебе застрять в первом попавшемся подозрении.
Разберём два рабочих подхода - USE и RED, посмотрим на их связь с "золотыми сигналами" Google, и научимся не наступать на классические грабли. Всё актуально на 2026 год.
Метод USE: как смотреть на железо и ресурсы
USE придумал Brendan Gregg, инженер по производительности (бывший Netflix, до этого Sun/Joyent). Идея гениально простая. Для КАЖДОГО ресурса системы проверь три вещи:
- U - Utilization (загрузка): какую долю времени ресурс был занят работой. Диск был занят обслуживанием запросов 90% времени - утилизация 90%.
- S - Saturation (насыщение): сколько работы стоит в очереди и НЕ может быть обслужено прямо сейчас. Это длина очереди. Ресурс может быть загружен на 100%, но если очереди нет - он справляется. А вот очередь - это уже боль.
- E - Errors (ошибки): счётчики ошибок. Сбойные пакеты, ошибки диска, отброшенные соединения, события OOM.
Вот таблица USE для основных ресурсов - её стоит держать перед глазами, пока не выучишь:
Код: Выделить всё
Ресурс | Utilization | Saturation | Errors
---------+--------------------+---------------------------+-------------------------
CPU | %usr+%sys (mpstat) | r в vmstat > числа vCPU | редко (MCE в dmesg)
Память | used/total (free) | si/so в vmstat, swap, PSI | OOM-killer в dmesg/journal
Диск | %util в iostat | aqu-sz, await в iostat,PSI | errors в smartctl, dmesg
Сеть | RX/TX bytes (sar) | дропы, overruns, backlog | errors в ip -s link
Главная мысль, которую новичок часто упускает: загрузка и насыщение - РАЗНЫЕ вещи. 100% загрузки CPU - это нормально, если работа делается и очередь пустая. А вот очередь из 8 процессов на 4 ядрах - это уже тревога, даже если "процент" выглядит не так страшно.
Практика: читаем USE-метрики по полям
Хватит теории. Берём vmstat - первый инструмент диагностики Linux, который показывает USE сразу по CPU и памяти. Запускаем с интервалом 1 секунда (первая строка - средние с момента загрузки, её игнорируй, смотри на последующие):
Код: Выделить всё
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
9 0 0 124680 43120 980240 0 0 2 6 140 220 71 14 14 1 0
- r - число процессов в очереди на CPU (готовы бежать прямо сейчас, ждут ядро). Это САТУРАЦИЯ процессора. Здесь r=9. Если у тебя 4 vCPU, а r стабильно 9 - процессор перегружен, задачи стоят в очереди. Важно: на 2026 в современных ядрах r НЕ включает процессы в непрерывном сне (D-state) - они идут в b. Это исправили давно, но старые статьи всё ещё путают.
- b - процессы, заблокированные в ожидании (обычно ввод-вывод, uninterruptible sleep). Если b большое, а CPU простаивает - проблема не в процессоре, а в диске или сети.
- si/so - swap in/out, килобайты в секунду. Это насыщение памяти. На здоровой системе тут НОЛИ. Любые ненулевые si/so под нагрузкой - сигнал, что памяти не хватает и система своппит. Заметь: используемый объём swap (колонка swpd) сам по себе не страшен - тревожен именно поток si/so прямо сейчас.
- us/sy/id/wa/st - проценты CPU: пользовательский код / ядро / простой / ожидание ввода-вывода / steal (украдено гипервизором). us=71 sy=14 id=14 - процессор реально работает. Если бы id был 80, а тормозило - искать надо не тут. Высокий wa - упёрлись в диск. Высокий st на виртуалке (выше 5-10%) - сосед по гипервизору ест твоё время, и это не лечится изнутри VM.
Код: Выделить всё
$ iostat -xz 1
Device r/s w/s rkB/s wkB/s r_await w_await aqu-sz %util
nvme0n1 12.0 340.0 192.0 44800.0 0.42 8.10 2.85 98.7
- %util - доля времени, когда к устройству шли запросы (утилизация полосы). 98.7% - устройство почти всегда занято. ВНИМАНИЕ, классическая ловушка: для HDD близкое к 100% значит насыщение, а вот для NVMe/SSD и RAID-массивов %util НЕ отражает реальный предел - они обслуживают запросы параллельно. NVMe может показывать 99% util и при этом иметь огромный запас. Поэтому на флеше смотри не на %util, а на aqu-sz и await.
- aqu-sz - средняя длина очереди запросов (в старых версиях называлась avgqu-sz). Это САТУРАЦИЯ диска. Считается как сумма очереди планировщика и запросов "в полёте" в устройстве. 2.85 - в среднем почти 3 запроса в очереди. Растёт - диск не успевает.
- r_await / w_await - среднее время обслуживания запроса чтения/записи в миллисекундах, ВКЛЮЧАЯ ожидание в очереди. w_await=8.10 мс для NVMe многовато (нормальный NVMe отвечает за доли мс - единицы мс), для HDD это норма. Это и есть latency, задержка, до которой мы ещё дойдём в курсе.
Код: Выделить всё
$ ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
RX: bytes packets errors dropped missed mcast
8123456 45012 0 127 0 3
TX: bytes packets errors dropped carrier collsns
6712345 38900 0 0 0 0
Современная альтернатива - PSI, единый взгляд на насыщение по всем ресурсам сразу:
Код: Выделить всё
$ cat /proc/pressure/io
some avg10=12.34 avg60=8.01 avg300=3.20 total=...
full avg10=4.10 avg60=2.50 avg300=1.05 total=...
$ cat /proc/pressure/cpu
some avg10=0.50 avg60=0.30 avg300=0.10 total=...
Метод RED: когда смотрим на сервис, а не на железо
USE отлично работает для ресурсов. Но он почти ничего не говорит про то, ЧТО чувствует пользователь твоего API. Здесь нужен RED, его сформулировал Tom Wilkie (на тот момент Weaveworks, ныне Grafana Labs) по мотивам "четырёх золотых сигналов" Google SRE. RED смотрит не на ресурс, а на сервис - на HTTP-эндпоинт, на очередь, на gRPC-метод:
- R - Rate: сколько запросов в секунду обрабатывает сервис (RPS).
- E - Errors: сколько из них завершились ошибкой (5xx, таймауты, ненулевой gRPC-код).
- D - Duration: распределение времени ответа. Не среднее! Среднее врёт. Смотри перцентили: p50, p95, p99.
Связь простая. USE отвечает на вопрос "ПОЧЕМУ медленно" (упёрлись в диск, кончилась память). RED отвечает на "НАСКОЛЬКО плохо пользователю" (95% запросов отвечают за 2 секунды вместо 200 мс). На практике их используют вместе: RED показал, что у сервиса вырос p99 и полезли 503-и - идёшь по USE и находишь, что диск в насыщении. RED - симптом, USE - причина.
Почему перцентили, а не среднее? Представь: 99 запросов по 10 мс и один за 5 секунд. Среднее - около 60 мс, выглядит отлично. Но один реальный пользователь ждал 5 секунд и ушёл. p99 эту боль покажет, а среднее её спрячет. И ещё тонкость: p99 одного запроса в цепочке из 10 микросервисов превращается в почти гарантированную медленноту хотя бы где-то - "хвосты" складываются. Запомни это намертво.
Антиметодологии: как НЕ надо (и почему мы все так делаем)
Прежде чем хвалить методы, признаем грехи. Brendan Gregg описал несколько "антиметодологий" - способов тратить время впустую:
- Метод уличного фонаря (street light). Анекдот: пьяный ищет ключи под фонарём не потому, что там их потерял, а потому что там светло. Так и мы: запускаем top, потому что умеем top, а не потому что проблема в CPU. Смотрим туда, где привычно, а не туда, где проблема.
- Случайное изменение (random change). Меняем параметр наугад ("а давай увеличим воркеров"), смотрим, не полегчало ли, откатываем, меняем следующий. Иногда срабатывает случайно - и это худшее, что может быть, потому что причину ты не понял, и она вернётся.
- Метод обвинения соседа (blame-someone-else). "Это сеть", "это база", "это не мой код" - и тикет улетает в чужую команду без единого доказательства.
Когда какой метод и куда он ведёт дальше
Простое правило выбора. Жалоба от пользователя или алерт по SLO ("API тормозит", "ошибки выросли") - заходи через RED, он на языке сервиса. Тревога от инфраструктуры или "весь хост колом" - заходи через USE, он на языке железа. В реальном инциденте маршрут обычно такой: RED ловит симптом -> USE локализует ресурс-виновник -> дальше идут инструменты глубокого анализа.
И вот тут важная актуализация на 2026. Раньше после USE сразу шли в strace и perf. Сегодня связка другая:
- strace всё ещё полезен для одного процесса, но он тормозит цель (каждый syscall - ловушка). Для системного трейсинга его вытесняет eBPF.
- eBPF дозрел: минимальное требование - ядро 5.4+ с включённым BTF, что на современных дистрибутивах (и 6.x в целом) есть из коробки. bpftrace для однострочников, BCC-инструменты для сложных утилит.
- Готовые bcc/bpftrace-инструменты ложатся прямо на USE: biolatency и biosnoop (задержки диска вместо гадания по iostat), execsnoop (кто и что запускает), tcplife и tcpretrans (сетевые соединения и ретрансмиты), runqlat (та самая сатурация CPU - сколько задачи ждут в очереди планировщика), oomkill. По сути это USE с точностью до отдельного события.
Мини-лаба: пройди USE руками прямо сейчас
Открой терминал на любой Linux-машине (можно на своей рабочей) и сделай полный проход USE по CPU, памяти и диску:
- Запусти vmstat 1, дай поработать 10 секунд. Найди колонки r, b, si, so, wa. Запиши: процессор насыщен (r > числа vCPU)? Память своппит (si/so > 0)?
- Узнай число ядер: nproc. Сравни с колонкой r.
- Запусти iostat -xz 1 (если нет - sudo apt install sysstat или sudo dnf install sysstat). Найди %util, aqu-sz и w_await по своему диску.
- Глянь насыщение через ядро: cat /proc/pressure/io и cat /proc/pressure/cpu. Запомни значения avg10 в покое.
- Посмотри ошибки сети: ip -s link. Есть ненулевые errors или dropped?
- Создай нагрузку и смотри, как метрики меняются. В одном окне stress-ng --cpu 4 --timeout 20s (или просто yes > /dev/null и потом Ctrl+C), в другом следи за vmstat. Увидишь, как растёт r, падает id, а в /proc/pressure/cpu подскакивает avg10.
- Бонус, если есть eBPF: sudo runqlat (из bcc-tools) во время нагрузки CPU - увидишь гистограмму времени ожидания в очереди планировщика. Это та самая сатурация из USE, но в микросекундах.
Контрольные вопросы
- Чем утилизация (Utilization) отличается от насыщения (Saturation)? Почему 100% загрузки CPU - это не всегда проблема?
- Почему на NVMe-диске нельзя ориентироваться на %util как на признак перегрузки, и на какие поля iostat смотреть вместо него?
- Какая колонка vmstat показывает насыщение CPU, а какая - насыщение памяти? Что считать тревожным значением?
- Почему для метрики Duration в RED берут перцентили (p95, p99), а не среднее время ответа? Откуда RED заимствовал свои сигналы?
USE - для ресурсов: по каждому (CPU, память, диск, сеть) проверь Utilization, Saturation, Errors. RED - для сервисов: Rate, Errors, Duration по перцентилям; оба растут из "четырёх золотых сигналов" Google. USE говорит почему медленно, RED - насколько больно пользователю. Загрузка и насыщение - не одно и то же: смотри на очереди (r в vmstat, aqu-sz в iostat) и на PSI в /proc/pressure, а не только на проценты; на флеше %util вообще обманчив. И главное - не ищи ключи под фонарём. Заведи чек-лист и иди по нему. На 2026 карту дают USE и RED, а лупу - eBPF (bpftrace/BCC) и perf, которые мы разберём в следующих уроках, чтобы анализ производительности Linux перестал быть лотереей.
