Первые 60 секунд: экспресс-диагностика нагруженного сервера

[Dmitry_SRE]

Звонок в три часа ночи: "сайт лежит", "всё тормозит", "сервер не отвечает". Ты подключаешься по SSH, и перед тобой чёрный экран с курсором. С чего начать? Можно час тыкать наугад, перезагружать сервисы и молиться. А можно за одну минуту понять, куда именно копать: процессор, память, диск или сеть. Этот урок - про второй путь.

Знаменитый чеклист "первые 60 секунд" придумал Брендан Грегг, перформанс-инженер из Netflix. Идея простая: есть набор из примерно десяти стандартных команд, которые есть почти на любом сервере. Прогоняешь их по очереди - и получаешь грубую, но честную картину: где узкое место. Это не глубокая диагностика, а скорее сортировка в приёмном покое. Задача - не вылечить, а быстро понять, в какую сторону бежать. Когда у тебя нагрузка на сервер Linux растёт, а причина неясна, этот чеклист экономит уйму нервов. Чеклисту уже больше десяти лет, но он держится: команды стабильны, а в 2026 к ним добавился свежий и очень мощный сигнал - PSI (о нём в конце практики).

С чего начать: load average и первые секунды

Первое, что делаешь после подключения, - смотришь на нагрузку. В диагностике Linux первые секунды почти всегда начинаются с одной команды:

Код: Выделить всё

uptime
 14:21:03 up 42 days,  3:11,  2 users,  load average: 9.41, 4.18, 1.92

Главное здесь - три числа в конце, это и есть load average. Они показывают среднюю длину очереди работы за последние 1, 5 и 15 минут. "Работа" - это процессы в состоянии R (крутятся на CPU или стоят в очереди на CPU) плюс процессы в состоянии D (непрерываемый сон, обычно ожидание диска или иногда блокировки в ядре). Важно: в Linux load average считает не только процессор, но и это самое D-ожидание. Поэтому высокий load - это ещё не обязательно "процессор перегружен". И ещё нюанс: load average - это экспоненциально сглаженное среднее, а не мгновенный замер, поэтому короткий пик в нём растворится, а долгий проявится.

Как читать? Сравнивай число с количеством ядер. Если у тебя 8 ядер, то load average около 8 - это полная, но здоровая загрузка. Load 9.41 на 8 ядрах - небольшой перегруз. А вот load 40 на 8 ядрах - это уже SOS. Сколько у тебя ядер (логических, с учётом hyper-threading), подскажет

Код: Выделить всё

nproc

. И ещё фокус: смотри на динамику трёх чисел. Тут 9.41 / 4.18 / 1.92 - значит проблема свежая, нагрузка резко выросла за последнюю минуту. Если бы было наоборот (1.9 / 4.1 / 9.4) - пик уже прошёл, сервер выдыхает.

Сразу следом - проверка, не ругалось ли ядро:

Код: Выделить всё

sudo dmesg -T | tail
[Sun Jun 14 14:19:55 2026] Out of memory: Killed process 30812 (php-fpm) total-vm:4519064kB, anon-rss:4399216kB
[Sun Jun 14 14:19:55 2026] oom-reaper: reaped process 30812 (php-fpm)

Флаг

Код: Выделить всё

-T

переводит время в человеческий вид (хотя на некоторых ядрах метки чуть плывут из-за способа учёта времени - сверяй с реальными часами). Если видишь строки про "Out of memory" и "Killed process" - это сработал OOM killer, ядру не хватило памяти и оно пристрелило процесс. Половина ночных инцидентов объясняется уже на этом шаге. Также высматривай "task ... blocked for more than 120 seconds" (зависший диск или ядерный дедлок), "nf_conntrack: table full" (переполнение таблицы соединений), сетевые дропы и MCE/железные ошибки. Совет на 2026: по горячим следам удобнее

Код: Выделить всё

journalctl -k -p err -b --no-pager

- это покажет сообщения ядра только текущей загрузки и только уровня error и выше, без шума.



Куда уходит время: CPU, своп и io-wait

Теперь крутим динамику. Команда

Код: Выделить всё

vmstat 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
12  0 131072 198400  44210 884512    0    0     8    62 5310 9921 88  9  1  2  0
14  1 131072 191020  44210 884600    0    0     0  1240 6102 11233 90  8  0  2  0

Что читать по колонкам:

• r - сколько процессов хотят CPU прямо сейчас (на ядрах + в очереди). Если r стабильно больше числа ядер - процессор узкое место. Тут r=12-14, и если ядер 8, то CPU явно затык.
• b - процессы, застрявшие в непрерываемом ожидании (обычно диск). Растёт b - подозревай диск или сетевую ФС.
• si / so - свопинг: страницы памяти читаются с диска (si) и выгружаются на диск (so). Любые ненулевые значения здесь, которые держатся, - тревога. Памяти не хватает, система свопит, и всё дико тормозит. Разовый всплеск so при старте тяжёлого процесса - терпимо, постоянный поток - беда.
• us / sy - время CPU в пользовательском коде и в ядре. Высокий us - грузит твоё приложение. Высокий sy (скажем, за 30%) - много системных вызовов, копай в сторону ядра/IO/сети/частых fork.
• wa - io-wait, доля времени, когда CPU простаивал в ожидании диска (и больше делать было нечего). wa под 30-50% - диск тормозит всю систему. Но помни: wa=0 при загруженном диске тоже бывает, если CPU есть чем заняться помимо ожидания.
• id - простой. id=0 значит процессор выжат досуха.
• st - steal time: время, украденное гипервизором у виртуалки. На облачном VPS ненулевой и растущий st - тебе не дают обещанный CPU, виноват сосед по гипервизору, а не твой код. На 2026 это частая причина "загадочных" тормозов в облаке.
• cs - переключения контекста в секунду. Аномально высокий cs (десятки-сотни тысяч) при низком полезном выходе - признак thread thrashing или слишком агрессивного планирования.

Здесь us=88-90, id=0 - классический CPU-bound: приложение упёрлось в процессор. Своп нулевой, wa маленький, st нулевой - память, диск и гипервизор ни при чём.

Дальше - баланс по ядрам. Общий процент может врать: вдруг одно ядро в полке, а семь спят?

Код: Выделить всё

mpstat -P ALL 1
07:42:01 PM  CPU   %usr  %nice  %sys %iowait  %irq  %soft  %idle
07:42:02 PM  all  41.20   0.00  3.10    0.25  0.00   0.50  54.95
07:42:02 PM    0  99.00   0.00  1.00    0.00  0.00   0.00   0.00
07:42:02 PM    1   2.00   0.00  1.00    0.00  0.00   0.00  97.00

Колонка CPU - номер ядра (all - среднее). Видишь: ядро 0 в полке (%idle=0), ядро 1 почти спит. Это типичная однопоточная нагрузка - программа не умеет параллелиться, и наращивать число ядер бесполезно (поможет только более быстрое ядро или переписать код). Колонка %iowait по ядрам, а %soft - софтовые прерывания (часто это обработка сети; если одно ядро завалено %soft, ты упёрся в один RX-очередь сетевой карты - лечится включением RSS/RPS, чтобы прерывания разъехались по ядрам). %irq - аппаратные прерывания.

Кто виноват: процессы, диск, память и сеть

Поняли, что ресурс жрут, - найдём пожирателя.

Код: Выделить всё

pidstat 1

похож на top, но печатает прокручиваемый лог, по которому удобно сравнивать секунды (а ещё его вывод легко grep-нуть и приложить к тикету):

Код: Выделить всё

pidstat 1
07:45:12 PM   UID    PID   %usr %system  %guest   %CPU  CPU  Command
07:45:13 PM  1000  30877  98.00    2.00    0.00 100.00    0  php-fpm
07:45:13 PM   999   1442   5.00    1.00    0.00   6.00    3  mysqld

Колонка %CPU - сколько процессор ест процесс (может быть больше 100% на нескольких ядрах: 100% = одно ядро целиком). Тут php-fpm с PID 30877 съел целое ядро. Вот наш клиент. Полезные родственники:

Код: Выделить всё

pidstat -d 1

покажет дисковый ввод-вывод по процессам (kB_rd/s, kB_wr/s, iodelay), а

Код: Выделить всё

pidstat -w 1

- переключения контекста по процессам.

Теперь диск.

Код: Выделить всё

iostat -xz 1

(флаг -x - расширенная статистика, -z - прятать неактивные диски):

Код: Выделить всё

iostat -xz 1
Device   r/s    w/s   rkB/s    wkB/s  r_await w_await  aqu-sz  %util
nvme0n1  12.0  430.0   192.0  84320.0    0.30   18.50    7.90   99.20

Ключевые поля:

• r/s, w/s - операций чтения и записи в секунду (это и есть IOPS). Тут активная запись (w/s=430).
• r_await, w_await - среднее время обслуживания запроса в миллисекундах (ожидание в очереди + сам обмен). Для NVMe доли мс - норма, для SATA SSD несколько мс - норма, для HDD 10-20 мс - норма. 50-100+ мс на любом устройстве - беда. Здесь w_await=18.5 мс для NVMe - запись явно подтормаживает (очередь забита).
• aqu-sz - средняя длина очереди к устройству (в новых sysstat поле так и называется aqu-sz, в старых - avgqu-sz). Стабильно больше 1-2 на HDD - диск не успевает; для NVMe нормальная очередь может быть и десятки, тут смотри в связке с await.
• %util - доля времени, когда устройству был отправлен хотя бы один запрос. ВАЖНО и актуально на 2026: начиная с ядер 4.17+ %util в iostat считается иначе и для SSD/NVMe откровенно обманывает - эти устройства обрабатывают много запросов параллельно, и 100% util НЕ значит "конец" и насыщение. На NVMe ориентируйся в первую очередь на await и на достигнутые IOPS/пропускную способность относительно паспорта диска, а %util используй только как грубый индикатор "диск вообще работает".

Память отдельно и наглядно -

Код: Выделить всё

free -m

(в мегабайтах; на 2026 чаще пишут

Код: Выделить всё

free -h

для авто-единиц):

Код: Выделить всё

free -m
              total    used    free   shared  buff/cache  available
Mem:          15884   12030     410      302        3444        3210
Swap:          2047    1850       8

Не пугайся маленького free - Linux намеренно набивает свободную память кешем страниц (buff/cache), это хорошо: кеш отдаётся приложениям мгновенно, как только понадобится. Смотри на колонку available - вот сколько реально доступно приложениям без свопа (ядро прикидывает это с учётом сбрасываемого кеша). Если available близко к нулю, а Swap used большой и растёт - памяти нет, жди тормозов и OOM. Кстати, в эпоху cgroup v2 (она по умолчанию во всех свежих дистрибутивах 2026 - Debian 12+, Ubuntu 22.04+, RHEL 9+, свежие Astra/RED OS) общая память может быть свободна, но конкретный сервис упирается в свой memory.max в cgroup - тогда его убьёт cgroup-OOM, а в

Код: Выделить всё

free

будет тишина. Проверяй

Код: Выделить всё

systemctl status имя.service

и

Код: Выделить всё

journalctl -u имя.service

.

Под конец - сеть.

Код: Выделить всё

sar -n DEV 1

:

Код: Выделить всё

sar -n DEV 1
07:50:01 PM IFACE  rxpck/s  txpck/s  rxkB/s   txkB/s  %ifutil
07:50:02 PM eth0  48200.0  51100.0 41200.0  58300.0   58.20

rxkB/s / txkB/s - принято и отправлено килобайт в секунду, rxpck/s / txpck/s - пакеты. Прикинь к ширине канала: гигабит - это около 125000 кБ/с (минус накладные расходы реально ниже). %ifutil подсказывает загрузку интерфейса. Аномально высокий pps при низком kB/s - признак мелких пакетов, часто это DDoS или флуд. Грегг советует добавить второй вызов -

Код: Выделить всё

sar -n TCP,ETCP 1

: тут смотри retrans/s (ретрансмиты TCP - сигнал потерь и проблем сети либо перегруза сервера), active/s (исходящие соединения) и passive/s (входящие). Растущий retrans/s при тормозах - крепкий намёк, что копать надо в сеть.

И только теперь имеет смысл открыть

Код: Выделить всё

top

(или

Код: Выделить всё

htop

) - живой обзор, чтобы подтвердить виновника глазами. В top держи в голове: колонка %CPU тоже бывает больше 100%, S - состояние процесса (R - бежит, D - тот самый непрерываемый сон, Z - зомби).

Финальный аккорд 2026 - PSI. Pressure Stall Information появилась в ядре 4.20 и сегодня есть на любом современном сервере. Это самый честный ответ на вопрос "из-за какого ресурса реально тормозят задачи":

Код: Выделить всё

cat /proc/pressure/cpu /proc/pressure/io /proc/pressure/memory
some avg10=12.30 avg60=8.10 avg300=3.40 total=...
full avg10=0.00  avg60=0.00 avg300=0.00 total=...   (для io/memory full бывает >0)

Поле some avg10 - процент времени за последние 10 секунд, когда хотя бы одна задача стояла в ожидании этого ресурса; full - когда стояли ВСЕ задачи (полная заморозка по ресурсу). io/memory full avg10 заметно больше нуля - это прямое, без догадок, доказательство дискового или мемори-затыка. PSI работает и по cgroup (cpu.pressure, io.pressure, memory.pressure в каждой группе), так что в контейнерах ты сразу видишь, какой именно сервис душится. Это уже не косвенные us/wa, а прямое измерение страдания.

Типичные грабли и заблуждения

• "Высокий load = перегружен процессор". Нет. В Linux load учитывает ещё и непрерываемый сон (ожидание диска). Высокий load при низком %CPU и большом wa - это диск, а не процессор.
• "Мало free памяти - надо срочно чистить". Нет, buff/cache отдаётся приложениям мгновенно при нужде. Смотри available, а не free. Чистить кеш через drop_caches на проде - почти всегда вредный карго-культ.
• Первую строку vmstat/iostat/mpstat принимать всерьёз. Она усреднена с момента загрузки и почти всегда врёт про "сейчас". Бери вторую и дальше.
• %util=100% на NVMe - паника. Для параллельных накопителей и на ядрах 4.17+ это не предел и не показатель насыщения. Доверяй await и достигнутым IOPS относительно паспорта диска.
• Забыть про steal и cgroup-лимиты. На облачном VPS тормоза часто это st в vmstat (украл гипервизор), а в контейнере - упёртый cpu.max/memory.max cgroup, при том что хост-метрики чистые.
• Команд может не быть из коробки. mpstat, pidstat, iostat, sar лежат в пакете sysstat - поставь

  Код: Выделить всё

  sudo apt install sysstat

  (Debian/Ubuntu/Astra) или

  Код: Выделить всё

  sudo dnf install sysstat

  (RHEL/Fedora/RED OS). Для непрерывного sar-сбора включи

  Код: Выделить всё

  sudo systemctl enable --now sysstat

  . На Astra Linux и RED OS набор тот же, имена пакетов совпадают.

Мини-лаба: повтори руками прямо сейчас

• Узнай число ядер:

  Код: Выделить всё

  nproc

  . Запиши.
• Прогони весь чеклист по порядку на своей машине:

  Код: Выделить всё

  uptime

  ,

  Код: Выделить всё

  journalctl -k -p err -b --no-pager | tail

  ,

  Код: Выделить всё

  vmstat 1

  (Ctrl+C через пять строк),

  Код: Выделить всё

  mpstat -P ALL 1

  ,

  Код: Выделить всё

  pidstat 1

  ,

  Код: Выделить всё

  iostat -xz 1

  ,

  Код: Выделить всё

  free -h

  ,

  Код: Выделить всё

  sar -n DEV 1

  ,

  Код: Выделить всё

  sar -n TCP,ETCP 1

  ,

  Код: Выделить всё

  top

  .
• Создай искусственную нагрузку на CPU:

  Код: Выделить всё

  yes > /dev/null &

  (потом не забудь

  Код: Выделить всё

  kill %1

  ). Снова глянь uptime и mpstat - увидь, как одно ядро уходит в полку, а load average медленно ползёт вверх.
• Посмотри живой PSI под нагрузкой:

  Код: Выделить всё

  cat /proc/pressure/cpu

  до запуска yes и через минуту после - сравни avg10 в строке some.
• Сравни load average с числом ядер и сделай вывод: перегруз или норма.

Контрольные вопросы

• На сервере 4 ядра, load average 12.0. Это перегруз или нет, и во сколько раз очередь длиннее ёмкости?
• В выводе vmstat колонки si и so показывают ненулевые значения, которые держатся. О чём это говорит и почему это плохо?
• iostat показывает %util=100% на NVMe-диске. Можно ли сразу делать вывод о насыщении? На какое поле смотреть вместо этого?
• free -h показывает free всего 200 МБ, но available 6000 МБ. Стоит ли паниковать из-за нехватки памяти и почему?
• vmstat на облачном VPS показывает st=25 при низком us. Что это значит и кто виноват - твой код или нет?

Что запомнить

Чеклист первых 60 секунд - это не магия, а дисциплина. Десяток команд по порядку дают грубую карту: uptime и dmesg/journalctl -k говорят "всё ли горит", vmstat и mpstat - "процессор, ожидание или украденное гипервизором время", pidstat - "кто виноват", iostat - "диск ли это", free - "хватает ли памяти", sar - "что с сетью и есть ли ретрансмиты", а PSI из /proc/pressure - прямой ответ "из-за какого ресурса реально стоят задачи". Главное - не вываливать команды, а читать их вывод: сравнивать load с числом ядер, помнить про io-wait и steal, не путать кеш с занятой памятью, держать в уме cgroup-лимиты и не верить %util на NVMe. Эта минута не лечит, но точно показывает, в какую сторону копать дальше. А копать глубже - strace, perf и eBPF (bpftrace, bcc-инструменты вроде biolatency и execsnoop) - мы будем в следующих уроках.

[grumpytoaster]

Спасибо, реально разложили по полочкам. Я раньше видел load average 8 и сразу паниковал, а у меня 16 ядер. Теперь буду сначала nproc смотреть, и про PSI вообще не знал - круто что прямо показывает из-за чего стоим.

[pandas_kun]

А подскажите, если в dmesg чисто и vmstat показывает wa под 40, но iostat говорит await всего 3 мс на NVMe - это всё равно диск виноват или где-то ещё затык? Глянул /proc/pressure/io, там some avg10 почти ноль. Куда копать дальше, в сеть или в само приложение?