Карта инструментов Linux по подсистемам
Главную идею подарил Брендан Грегг (Brendan Gregg) - инженер, который нарисовал знаменитую карту инструментов наблюдаемости Linux (Linux Performance Observability Tools). Суть: система состоит из слоев (приложение, библиотеки, системные вызовы, ядро и его подсистемы, железо), и под каждый слой есть свои утилиты. Если держать эту карту в голове, анализ производительности linux перестает быть гаданием. Вот она по подсистемам, с актуальными на 2026 акцентами:
- Приложение - что делает сам процесс. Инструменты: perf (профилирование стеков и flame graphs), strace (трассировка системных вызовов), ltrace (вызовы библиотек), gdb для точечной отладки.
- Системные вызовы - граница между процессом и ядром. Тут strace, perf trace, а из eBPF - bpftrace и готовые инструменты execsnoop (новые процессы), opensnoop (какие файлы открываются), syscount (гистограмма вызовов).
- Файловые системы и блочный слой - диски. iostat (статистика по устройствам), iotop (кто грузит диск), а на eBPF - biolatency (латентность блочного I/O гистограммой), biosnoop (каждый запрос с PID и временем), ext4slower/xfsslower (медленные операции ФС). blktrace остается, но в 2026 чаще берут eBPF - он легче и нагляднее.
- Сеть - сокеты и пакеты. ss (состояние сокетов, давно заменил netstat), ip (интерфейсы и маршруты), tcpdump (захват пакетов), а на eBPF - tcplife (жизнь TCP-соединений с байтами и временем), tcpretrans (ретрансмиты без флуда tcpdump), tcpconnect.
- Планировщик и память - top, vmstat, pidstat, free, slabtop. На eBPF - runqlat (задержка в очереди планировщика), runqlen, cachestat (попадания в page cache). Сюда же sar для исторической картины.
- CPU - mpstat (загрузка по ядрам), perf (циклы, кэш-промахи, профиль по событиям PMU), turbostat (реальная частота, C-состояния, энергопотребление).
Методология USE: как не утонуть в утилитах
Карта отвечает на вопрос "чем смотреть", но не "что смотреть". Для этого есть метод USE того же Грегга. Расшифровка: Utilization (утилизация - доля времени, что ресурс занят работой), Saturation (насыщение - есть ли очередь работы, которую ресурс не успевает обработать), Errors (ошибки). Идея простая: для каждого ресурса проверь утилизацию, насыщение и ошибки. Как чек-лист пилота перед взлетом - быстро, полно, без пропусков. Грегг утверждает, что так решается большинство типовых проблем малыми усилиями, потому что ты системно обходишь все ресурсы, а не цепляешься за первый попавшийся график.
Самое важное для новичка - различать утилизацию и насыщение. Утилизация 100 процентов сама по себе не катастрофа: ресурс просто полностью используется, и это может быть желаемым (зачем платить за простаивающее железо). А вот насыщение - это очередь, ожидание, и именно оно превращается в тормоза для пользователя. Простой образ: касса в магазине. Кассир пробивает без перерыва - это утилизация 100 процентов. Очередь из десяти человек за кассой - это насыщение. Тормозит людей именно очередь, а не занятость кассира.
Где смотреть эти три метрики по ресурсам:
- CPU: утилизация - mpstat -P ALL, top (поля us+sy); насыщение - load average и поле "r" в vmstat (число процессов в очереди на выполнение), точнее - runqlat из eBPF.
- Память: утилизация - free -h, /proc/meminfo (важно: available, а не free); насыщение - своппинг (поля si/so в vmstat), срабатывания OOM-killer в dmesg или journalctl -k, и метрики PSI в /proc/pressure/memory.
- Диск: утилизация и насыщение - iostat -xz (колонки %util, aqu-sz, await), а точнее по латентности - biolatency.
- Сеть: утилизация - sar -n DEV, ip -s link; ошибки и дропы - ip -s link (errors, dropped), ss -s, nstat.
Сквозной разбор инцидента: linux мониторинг в бою
Теперь самое ценное - проживем инцидент целиком. Симптом: linux мониторинг прислал алерт, что веб-сервис отвечает с задержкой 2 секунды вместо обычных 50 мс. Идем по USE сверху вниз, не перепрыгивая шаги.
Шаг 1. Общая картина за 60 секунд. Грегг предлагает начинать с быстрого осмотра (его чек-лист "первых 60 секунд"). Запускаем vmstat с интервалом 1 секунда:
Код: Выделить всё
$ 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
2 18 0 198432 10220 540112 0 0 14 980 520 1100 4 3 12 81 0
1 19 0 195880 10220 541004 0 0 8 1024 540 1180 5 4 9 82 0Шаг 2. Подтверждаем по дискам. Спускаемся на блочный слой:
Код: Выделить всё
$ iostat -xz 1 3
Device r/s w/s rkB/s wkB/s r_await w_await aqu-sz %util
nvme0n1 12.0 480.0 200.0 122000.0 1.20 198.50 92.30 99.80Шаг 3. Находим процесс. Кто пишет на диск:
Код: Выделить всё
$ sudo iotop -oP
PID PRIO USER DISK READ DISK WRITE COMMAND
4412 be/4 www 0.00 B/s 118.20 M/s php-fpm: pool www
4418 be/4 www 0.00 B/s 3.10 M/s php-fpm: pool wwwШаг 4. Что именно он пишет. Спускаемся на слой системных вызовов и трассируем процесс (флаги: -f включая потоки, -p подключиться к PID, -e trace фильтр по вызовам):
Код: Выделить всё
$ sudo strace -f -p 4412 -e trace=write
[pid 4412] write(7, "DEBUG: query took 0.4ms full row"..., 8192) = 8192
[pid 4412] write(7, "DEBUG: query took 0.5ms full row"..., 8192) = 8192Код: Выделить всё
$ sudo bpftrace -e 'tracepoint:syscalls:sys_enter_write /pid == 4412/ { @bytes = hist(args->count); }'Типичные грабли и заблуждения
- load average - это не загрузка CPU. В Linux в load average входят и процессы в состоянии D (ждут диск, состояние uninterruptible sleep). Высокий load при низком us/sy в top - почти всегда I/O, а не процессор. Чтобы увидеть это явно, смотри колонку wa и количество процессов в b в vmstat.
- Высокий %util диска не значит "диск умирает". Для NVMe и SSD с параллельными очередями %util=100 может быть нормой. Смотри на await и aqu-sz, латентность важнее процента занятости. Это одна из главных ловушек, перешедших из эпохи вращающихся дисков.
- strace тормозит цель. Он останавливает процесс на каждом системном вызове (механизм ptrace) и может замедлить горячий сервис в разы, иногда на порядок. На проде по горячим путям бери perf trace или bpftrace - они на порядки дешевле и не ставят процесс на паузу.
- free показывает мало "free" - паника. Linux намеренно отдает свободную память под page cache (колонки buff/cache). Свободная память, которую можно отдать процессам, - это поле available в free -h, а не free. Низкий free при высоком available - норма.
- Начинать с tcpdump. Классическая ошибка - сразу лезть в пакеты. Сначала USE по всем ресурсам, и только если виновата сеть - доставай захват, а лучше ss и tcpretrans, чтобы не утонуть в гигабайтах дампа.
Не закрывай терминал, сделай это на любой тестовой машине (не на проде):
- Запусти искусственную нагрузку на диск: dd if=/dev/zero of=/tmp/lab.bin bs=1M count=4096 oflag=direct (если direct не поддержан файловой системой, убери oflag).
- В соседнем терминале смотри vmstat 1 - найди рост колонки wa и bo, и процессы в b.
- Параллельно запусти iostat -xz 1 и понаблюдай %util, w_await, aqu-sz на своем диске - это твой шаг 2 из кейса вживую.
- Если ядро 5.2 или новее и стоит bpftrace - запусти sudo bpftrace -e 'tracepoint:block:block_rq_complete { @ = hist(args->nr_sector); }' и посмотри гистограмму размеров запросов. Так выглядит eBPF-наблюдаемость.
- Нагрузи CPU: yes > /dev/null & и поймай разницу - теперь в vmstat растут us и колонка r, а wa остается низким. Прочувствуй, чем CPU-bound отличается от I/O-bound. Не забудь kill %1.
- Удали /tmp/lab.bin.
Куда расти дальше
Ты прошел путь от чтения логов до strace, perf и eBPF. Следующая ступень - книга Брендана Грегга "BPF Performance Tools" и его сайт brendangregg.com: там и полная карта инструментов наблюдаемости, и больше 150 готовых eBPF-утилит. Актуальная на 2026 деталь: классические инструменты bcc на Python считаются устаревшим способом, проект переехал на libbpf-tools (C + BTF + CO-RE) - это компактные бинарники без зависимостей, которые собираются один раз и работают на разных ядрах. Для CO-RE нужно ядро 5.2 или новее с включенным CONFIG_DEBUG_INFO_BTF, что в современных дистрибутивах с systemd уже по умолчанию (в Astra Linux и RED OS свежих веток - тоже, но версию ядра стоит проверить заранее). Дальше - в сторону наблюдаемости (метрики, трейсинг, Prometheus, Grafana, OpenTelemetry) и культуры SRE, где диагностика производительности linux становится не подвигом в три часа ночи, а рутиной с метриками, SLO и заранее заготовленными дашбордами. Карта и метод USE остаются с тобой - подсистемы и очереди работают одинаково везде.
Контрольные вопросы
- Чем утилизация ресурса отличается от насыщения, и какая из этих метрик обычно и есть причина тормозов для пользователя?
- В выводе vmstat ты видишь wa=80, r=1, si/so=0, много процессов в b. На какую подсистему это указывает и какой инструмент возьмешь следующим?
- Почему по %util нельзя судить о пределе NVMe-диска, и на какие две колонки iostat смотреть вместо него?
- Почему strace опасно запускать на горячем продакшен-процессе и чем его заменить в 2026?
Инструментов много, но порядок один: карта Грегга подсказывает, чем смотреть на каждом слое, а метод USE (утилизация, насыщение, ошибки) - что именно проверять. Сначала находи подсистему-виновника по общему снимку, потом спускайся к процессу и к конкретному системному вызову, не перепрыгивая через шаги. Не начинай с узких инструментов и помни про цену strace на проде - по горячим путям бери eBPF. Высокий iowait - вниз к диску. Высокий load при низком CPU - тоже почти всегда диск. Для SSD и NVMe верь латентности (await) и очереди (aqu-sz), а не проценту %util. Методология бьет случайное тыканье каждый раз - и это главный итог всего курса.
