Производительность: урок по Linux к собеседованию

«Сервер тормозит, разберись» это вопрос не про знание флагов, а про методику. Хороший ответ: за первые минуты понять, какой ресурс упёрся (CPU, память, диск, сеть) и кто его ест, а не перезагружать наугад.

Методика USE

Для каждого ресурса проверь три вещи (метод Брендана Грегга):

Utilization: насколько ресурс занят.
Saturation: есть ли очередь (ждут ли его).
Errors: есть ли ошибки.

Ресурсы: CPU, память, диски, сеть. Так ты не пропустишь очевидное и не утонешь в деталях.

Load average

uptime
# 10:15:01 up 12 days,  load average: 7.80, 4.10, 2.05

Три числа: среднее за 1, 5 и 15 минут. Это среднее число задач, которые выполняются или ждут CPU, плюс в Linux ещё задачи в состоянии D (непрерываемое ожидание, обычно диск). Поэтому:

load 8 на 8 ядрах может быть нормой, на 2 ядрах это очередь;
высокий load при простаивающем CPU почти всегда означает ожидание ввода-вывода;
7.8 / 4.1 / 2.0 значит, что нагрузка растёт прямо сейчас.

Число ядер: nproc.

top и htop

Шапка top:

%Cpu(s): 12.0 us,  3.0 sy,  0.0 ni, 40.0 id, 44.0 wa,  0.0 hi,  1.0 si,  0.0 st

us: пользовательский код, sy: ядро, ni: процессы с nice.
id: простой.
wa (iowait): CPU простаивает, пока есть незавершённый ввод-вывод. Высокий wa указывает на диск.
st (steal): гипервизор отдал время другим виртуалкам. Высокий steal в облаке значит «соседи шумят» или упёрлись в лимит инстанса.

В списке процессов: RES резидентная память, %CPU (может быть больше 100% у многопоточного процесса), S состояние. Клавиши: P сортировка по CPU, M по памяти, 1 по ядрам, H потоки.

vmstat: общий срез

vmstat 1 5
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 812000  12000 900000    0    0     4    20 2100 4200 95  5  0  0  0

r: в очереди на CPU. Больше числа ядер значит нехватка CPU.
b: в непрерываемом ожидании (диск).
si/so: своп туда-обратно. Постоянные ненулевые значения значат нехватку памяти.
bi/bo: блоки чтения и записи.
cs: переключения контекста.

Первая строка это среднее с момента загрузки, смотрят со второй.

iostat: диски

iostat -xz 1
Device  r/s   w/s  rkB/s  wkB/s  r_await w_await aqu-sz  %util
nvme0n1 120  900   4800  72000     0.4    18.5    16.2   99.8

r_await/w_await: среднее время операции в мс, включая очередь. Для SSD единицы мс уже много.
aqu-sz: средняя длина очереди.
%util: доля времени, когда устройство было занято. Для HDD 100% значит насыщение, для SSD и NVMe, которые выполняют много запросов параллельно, 100% ещё не предел; смотри на await и очередь.

Кто именно пишет: iotop или pidstat -d 1.

pidstat, mpstat, sar

mpstat -P ALL 1: загрузка по ядрам. Одно ядро в 100% при остальных свободных значит однопоточное узкое место.
pidstat 1, pidstat -d 1, pidstat -r 1: CPU, диск, память по процессам.
sar: история метрик (если включён sysstat), например «что было ночью в 3:00».

Все они из пакета sysstat.

strace: что делает процесс

strace -p 1234 -f -tt -T          # системные вызовы живого процесса
strace -c -p 1234                 # сводка: какие вызовы и сколько времени
strace -e trace=network,file cmd  # только сеть и файлы

Помогает, когда процесс «завис» или медленный, а логов нет: видно, что он ждёт read из сокета, бесконечно делает open несуществующего файла или упёрся в futex. strace сильно замедляет процесс, на нагруженном проде применяют осторожно. Альтернатива с меньшими накладными расходами: perf и инструменты eBPF (bpftrace, bcc).

lsof и лимиты

lsof -p 1234            # открытые файлы и сокеты процесса
ls /proc/1234/fd | wc -l
cat /proc/1234/limits   # Max open files и другие

Too many open files значит, что исчерпан лимит дескрипторов (ulimit -n, у systemd LimitNOFILE). Иногда причина в утечке, а не в маленьком лимите.

perf: где тратится CPU

perf top показывает самые горячие функции в реальном времени, perf record -g с последующим perf report строит профиль, из которого делают flame graph.

Первые 60 секунд

uptime; dmesg -T | tail; vmstat 1 5; mpstat -P ALL 1 3
pidstat 1 3; iostat -xz 1 3; free -m; sar -n DEV 1 3; top

После этого обычно ясно, какой ресурс виноват.

Частые ошибки

Читать load average без учёта числа ядер и состояния D.
Считать высокий %util у NVMe доказательством насыщения.
Смотреть на первую строку vmstat.
Забывать про steal в облаке.
Запускать strace на самом нагруженном процессе в пик без понимания цены.

Что спросят на собесе

Что такое load average, может ли он быть высоким при свободном CPU.
Что значат wa и st в top.
Как найти процесс, который грузит диск.
Зачем нужен strace, приведи пример.
Методика разбора «сервер тормозит».

Производительность Linux за 8 минут