2026: iostat vs pidstat vs eBPF для диагностики дисковой задержки в продакшене

В 2026 году инструментов для диагностики дисковых задержек (disk latency) много, но реальная задача в продакшене почти всегда одна: быстро ответить на два вопроса — где возникает задержка и кто её создаёт. Если мониторинг показывает рост времени ответа БД, просадку TTFB или всплески iowait, то «снять графики» недостаточно: нужно связать симптомы с устройством, очередями и конкретными процессами/операциями.

Ниже — практичный разбор трёх подходов: iostat (срез по устройствам), pidstat (виновники по процессам/потокам) и eBPF (трассировки задержек на уровне ядра, включая iolatency и biolatency). Я пишу с прицелом на production troubleshooting: минимум магии, максимум сигналов.

Быстрая карта: что измеряет iostat, pidstat и eBPF

Важно понимать, что эти инструменты отвечают на разные вопросы и работают на разных уровнях наблюдаемости:

• iostat — «что происходит с дисками/томами»: загрузка устройства, очередь, средние задержки чтения/записи.
• pidstat — «кто делает I/O»: какие процессы генерируют чтения/записи и кто много времени проводит в ожиданиях.
• eBPF — «где именно теряется время»: измерение latency по событиям ядра и распределениям (гистограммы), а не только средним.

Если упрощать: iostat показывает симптом на устройстве, pidstat — подозреваемого в userspace, а eBPF помогает доказательно связать их и локализовать узкое место (очередь, scheduler, драйвер, сетевое/виртуальное хранилище, блок-слой).

iostat в 2026: быстрый индикатор «устройство болит»

iostat (пакет sysstat) — частый первый шаг: он дешёвый по накладным расходам, обычно уже установлен, и его легко интерпретировать в динамике «каждую секунду». Сила iostat — агрегированные метрики по устройству за интервал.

Какие поля iostat реально читать при инциденте

Набор колонок зависит от версии sysstat, но при анализе задержек обычно важны:

• %util — насколько устройство занято. 100% не всегда означает «плохо», но стабильный высокий %util вместе с ростом задержек — красный флаг.
• await — среднее время операции (включая ожидание в очереди). Это усреднение; хвосты p95/p99 оно маскирует.
• r_await / w_await — отдельно чтение/запись. Часто деградирует именно запись из‑за flush/fsync.
• avgqu-sz — средняя длина очереди. Рост очереди при росте await обычно означает насыщение.
• r/s, w/s, rkB/s, wkB/s — профиль нагрузки: много мелких IOPS или поток.

Минимальные команды iostat

Для «живого» наблюдения обычно достаточно:

iostat -xz 1

Быстрые правила интерпретации:

• Если await растёт, а %util низкий, проблема может быть выше/ниже «видимого» устройства: RAID/контроллер, виртуализация, сетевое backing storage, квоты/лимиты.
• Если %util около 100% и растёт avgqu-sz, устройство насыщено: не хватает IOPS, запросы стали тяжелее (случайность, мелкие блоки, синхронная запись).
• Если w_await значительно выше r_await, подозревайте синхронные записи, журналирование ФС, flush-ы, барьеры или поведение приложения (частые fsync).

Если вам нужен расширенный контекст по блочному вводу-выводу (планировщики, тесты, iotop/fio и т.д.), держите под рукой отдельный разбор: метрики I/O и диагностика диска: iostat, iotop, fio, scheduler.

Ограничения iostat

iostat не знает про процессы и не показывает распределения задержек. А в продакшене часто «убивает» именно хвост p99: среднее await может выглядеть приемлемо, но единичные операции по 200–500 мс в критическом пути ломают SLA.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

pidstat: быстро находим подозреваемого процесса

pidstat (sysstat) полезен тем, что показывает активность по процессам и потокам. Это хороший второй шаг после iostat: вы подтверждаете проблему на уровне устройства, а затем ищете, кто именно в этот момент активно читает/пишет.

Что смотреть в pidstat для I/O

В контексте дисковых задержек чаще всего используют:

• режим I/O по процессам: скорости чтения/записи и количество операций;
• ожидания (в широком смысле) — чтобы понять, кто «застревает».

Практика: команды pidstat

Срез I/O по процессам:

pidstat -d 1

Если нужно увидеть потоки (бывает, что один «шумный» thread решает всё):

pidstat -d -t 1

Если вы уже видите общую деградацию и хотите понять, какие процессы чаще «висят» в ожиданиях:

pidstat -w 1

Как связать iostat и pidstat в одном временном окне

1. По алерту фиксируете время начала деградации.
2. Запускаете iostat -xz 1 и проверяете: это именно устройство (очередь/задержка), а не просто рост iowait «на фоне».
3. Параллельно запускаете pidstat -d 1 и смотрите, какие процессы совпадают по времени со всплеском.

На практике здесь часто обнаруживается «фоновый киллер»: ротация и компрессия логов, бэкап, compaction, cron-задача, пересборка индексов. Иногда достаточно перенести расписание, ограничить параллелизм или изменить параметры приложения.

Ограничения pidstat

pidstat хорошо отвечает на «кто создаёт I/O», но плохо — на «почему latency прыгает». Он не показывает задержку каждой операции и не объясняет, в каком месте пути до устройства запрос теряет время. Ещё одна типовая проблема: процесс может «писать» в page cache, а реальные flush/commit пойдут позже (и иногда другим контекстом), поэтому корреляция не всегда прямая.

eBPF в 2026: когда нужны доказательства и хвосты задержек

eBPF — это следующий уровень наблюдаемости: вы измеряете задержки непосредственно в ядре на событиях блочного ввода-вывода и получаете распределения (гистограммы). Это особенно ценно, когда проблема проявляется «редкими пиками», а средние метрики выглядят терпимо.

Когда iostat отвечает «на устройстве есть задержка», а pidstat — «похоже, пишет процесс X», eBPF помогает ответить «какие именно операции дают хвост, на каком участке пути и насколько это системно».

iolatency vs biolatency: практическая разница

В BCC/bpftrace и похожих наборах утилит часто встречаются два класса инструментов:

• iolatency — ближе к тому, что ощущает приложение: задержки I/O в разрезе операций, часто с привязкой к процессам.
• biolatency — задержки на уровне блочного слоя (block I/O), ближе к очередям устройства и прохождению запросов через block layer.

Практический смысл такой: если приложение жалуется, а biolatency «чистая», ищите выше (ФС, блокировки, page cache, contention, лимиты cgroup). Если biolatency растёт вместе с симптомами — узкое место почти наверняка действительно в цепочке до устройства/хранилища.

Базовые команды eBPF для latency

Команды зависят от того, что именно установлено (bcc-tools, bpftrace-скрипты, утилиты дистрибутива). Часто начинают с таких утилит:

biolatency

iolatency

На что смотреть в гистограммах:

• в первую очередь на правый хвост: корзины на десятки/сотни миллисекунд уже требуют разбирательства;
• сравнивайте «норма» против «инцидент»: полезно снять 30–60 секунд в момент деградации и столько же в спокойный период.

Если вы только выстраиваете BPF-диагностику и хотите понять, что ставить и как безопасно применять в проде, поможет отдельная памятка: eBPF-диагностика: BCC и bpftrace для админов.

Когда eBPF реально незаменим

• Редкие, но огромные задержки: средний await «нормальный», а приложение уходит в таймауты.
• Спор «диск vs приложение»: biolatency помогает подтвердить или снять обвинение с блок-слоя.
• Сложная виртуализация или сетевое хранилище: iostat в госте видит только симптомы, а eBPF даёт более точную картину на уровне ядра.
• Смешанная нагрузка (БД + логи + бэкапы): хвосты могут давать не самые «жирные» по MB/s процессы.

Алгоритм troubleshooting: от симптома к корню проблемы

Ниже — рабочая последовательность, которая хорошо ложится на инциденты «всё стало медленно».

Шаг 1. Быстро подтвердить, что проблема похожа на I/O

Сначала отделяем I/O-историю от CPU/памяти/локов. Минимум команд на хосте:

uptime

vmstat 1

В vmstat обращайте внимание на wa, а также на общую картину: если растёт очередь runnable и одновременно растёт wa, это часто коррелирует с I/O-заторами (но само по себе не доказывает их).

Шаг 2. Локализовать проблемный девайс/том (iostat)

iostat -xz 1

Зафиксируйте конкретное устройство, на котором растут await, avgqu-sz, %util. В системах с несколькими томами часто «умирает» один, а страдает весь сервис из-за горячих путей (WAL/redo, tmp, логи, spool).

Шаг 3. Найти кандидата-виновника (pidstat)

pidstat -d 1

Смотрите процессы, которые совпадают по времени со всплеском. Если виновник очевиден, путь действий обычно прикладной: ограничить параллелизм, перенести тяжёлую задачу, изменить политику логирования, тюнингнуть параметры БД/фоновых задач.

Шаг 4. Если картина не сходится, включить eBPF на короткое окно

Когда iostat подтверждает задержки на устройстве, но pidstat не показывает явного лидера (или лидеров много), снимайте гистограммы:

biolatency

iolatency

Дальше вы отвечаете на другой вопрос: не «кто больше всех пишет», а «какие задержки реально есть и каков хвост». Это особенно полезно при проблемах «пачками» (bursty I/O) и при подозрении на синхронные операции.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Что выбрать для production monitoring: практичное сравнение

Держать постоянную трассировку в проде обычно не хочется. Типичная стратегия в 2026 году выглядит так:

• Постоянно: системные метрики уровня iostat (утилизация, очередь, средние задержки) через мониторинг.
• По запросу: pidstat-срезы во время инцидента (или короткие профили по расписанию, если это допускают политики).
• Точечно: eBPF на 30–120 секунд по алерту или при ручной диагностике, чтобы поймать хвосты и доказать место деградации.

Сравнение «в лоб»

• iostat: быстро, просто, дёшево; но нет привязки к процессам и нет распределений задержек.
• pidstat: помогает найти подозреваемых; но не показывает latency на уровне отдельных операций и не объясняет «где именно» в ядре теряется время.
• eBPF: максимально полезно для latency и хвостов; но требует аккуратности, прав, совместимости ядра и дисциплины применения.

Частые ловушки при анализе disk latency

• Ориентироваться только на средние: await выглядит нормально, но p99 огромный.
• Считать, что 100% util всегда плохо: на NVMe при высокой параллельности это может быть нормой, пока latency стабильна.
• Путать I/O устройства и I/O процесса: процесс может писать в page cache, а реальный flush случится позже.
• Не учитывать фоновые задачи: бэкапы, ротации, проверки целостности, обслуживание индексов могут быть «тихими» по CPU, но критичными по диску.

Вывод: как думать про iostat vs pidstat vs eBPF

• Начинайте с iostat, чтобы подтвердить проблему на уровне устройства и оценить масштаб.
• Переходите к pidstat, чтобы быстро найти процессы-кандидаты и устранить очевидные причины.
• Подключайте eBPF, когда нужно поймать хвосты, доказать источник задержки и получить данные уровня «вот здесь и вот так» (через iolatency/biolatency).

Такой стек хорошо работает и для инцидентов, и для выстраивания мониторинга: дешёвые метрики — постоянно, точные трассы — коротко и по событию.

Если сервис крутится на хостинге или вы планируете перенос, закладывайте запас по дисковой подсистеме и возможность быстрого доступа к системным метрикам. Для проектов с предсказуемой нагрузкой часто достаточно виртуального хостинга, а для задач с «пиками» и требованиями к производительности I/O удобнее масштабироваться на VDS.