iostat и iotop: диагностика дисковой нагрузки в Linux

Высокая загрузка диска редко выглядит как «диск сломался». Чаще сайт начинает отвечать медленнее, API периодически уходит в таймауты, база данных внезапно копит очередь запросов, а load average растёт при нормальном CPU. В таких случаях нужно быстро понять: дисковая подсистема действительно узкое место или приложение ждёт чего-то другого.

Для первичной диагностики в Linux обычно хватает двух утилит: iostat показывает картину по устройствам — сколько операций чтения и записи идёт, какая задержка, насколько занят диск; iotop отвечает на другой вопрос — какой процесс прямо сейчас создаёт I/O-нагрузку.

Эти инструменты особенно полезны рядом с метриками доступности: если внешний мониторинг фиксирует деградацию сайта, а на сервере в это же время видны пики await, %util или активная запись конкретного процесса, расследование становится короче.

Когда подозревать дисковую нагрузку

Проблемы с диском не всегда проявляются как ошибки в логах. Часто приложение продолжает работать, но делает это медленно и нестабильно. Типичные симптомы:

1) Растёт load average, но CPU не загружен — процессы ожидают I/O: они не потребляют процессор, но учитываются в очереди на выполнение. Подробнее: что такое load average в Linux.

2) Увеличивается latency API или сайта — запросы дольше ждут чтения из базы, записи логов, fsync или обращения к сетевому хранилищу. Если проблему видят пользователи, её удобно сопоставить с внешними проверками доступности: например, Statuser проверяет сайт с заданным интервалом и присылает уведомление о сбое, что помогает зафиксировать момент деградации, а не разбирать её «по ощущениям».

3) База данных «тупит» без очевидной причины — медленные запросы могут быть следствием не только плохих индексов, но и задержки диска, особенно при checkpoint, VACUUM, ALTER TABLE, массовых импортах и бэкапах.

4) В логах появляются таймауты и 5xx — backend не успевает получить ответ, база не отвечает вовремя, upstream закрывает соединение. На уровне пользователя это выглядит как 502, 503 или 504.

5) Бэкапы, ротация логов или аналитика совпадают с пиками нагрузки — ночной rsync, mysqldump, архивация логов или пересчёт отчётов конкурируют с продакшен-нагрузкой за один и тот же диск.

iostat и iotop не заменяют полноценный мониторинг, но хорошо подходят для быстрого ответа: «упёрлись ли мы в диск прямо сейчас?»

Установка iostat и iotop

iostat входит в пакет sysstat. В большинстве дистрибутивов он ставится из стандартных репозиториев.

# Debian / Ubuntu
sudo apt update
sudo apt install sysstat iotop
 
# RHEL / CentOS / Rocky / AlmaLinux
sudo dnf install sysstat iotop
 
# Arch Linux
sudo pacman -S sysstat iotop

Проверить версии:

iostat -V
iotop --version

Для iotop обычно нужны права root, потому что утилита читает данные по задачам ядра. Запускайте её через sudo.

Иногда iotop сообщает, что ядро не поддерживает нужные опции. Для работы требуются CONFIG_TASKSTATS, CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING и связанные механизмы учёта. На обычных серверных ядрах популярных дистрибутивов всё уже включено, но в минимальных или кастомных окружениях бывают исключения.

sysstat также может собирать исторические данные через sar, если включён соответствующий сервис. Для разовой диагностики это не обязательно: iostat работает сразу после установки.

iostat: базовая команда для диагностики

Самый полезный запуск:

iostat -xz 1

Расшифровка:

• -x — расширенная статистика по устройствам;
• -z — не показывать устройства без активности;
• 1 — обновлять вывод каждую секунду.

Есть нюанс: первый блок вывода iostat часто показывает средние значения с момента загрузки системы, и для текущей ситуации он может быть бесполезен. Смотрите второй и последующие интервалы. В некоторых версиях можно использовать -y, чтобы пропустить первый отчёт:

iostat -xz -y 1

Полезные варианты:

1) Статистика в мегабайтах — удобно для оценки throughput: iostat -xmz 1.

2) Конкретный диск — если на сервере много устройств: iostat -xz 1 nvme0n1.

3) Разделы — полезно, когда нужно отличить активность корневого раздела от отдельного тома под базу: iostat -xz -p 1.

4) Несколько измерений и выход — удобно для вставки в тикет или инцидент: iostat -xz 1 10.

5) CPU и устройства вместе — по умолчанию iostat показывает оба блока, если не указан только режим дисков. В CPU-блоке интересны iowait, user, system, idle.

Пример фрагмента вывода:

Device            r/s     w/s   rkB/s   wkB/s  r_await  w_await  aqu-sz  %util
nvme0n1          25.0   310.0  2048.0  98560.0    0.45     8.90    2.80  92.40
sda               0.0     3.0     0.0    120.0    1.20    15.30    0.05   4.10

По этому выводу видно, что основная нагрузка идёт на nvme0n1: много записей, высокая утилизация, заметная задержка записи.

Как читать метрики iostat

iostat полезен только тогда, когда вы смотрите не на одну метрику, а на их сочетание. Ориентироваться лишь на %util или iowait опасно.

1) r/s и w/s — IOPS на уровне устройства, количество операций чтения и записи в секунду. Много мелких операций может создать проблему даже при небольшом объёме данных в MB/s.

2) rkB/s, wkB/s (или rMB/s, wMB/s) — throughput чтения и записи. Важен для последовательных операций: бэкапов, дампов, копирования файлов, аналитических сканов.

3) await — среднее время выполнения I/O-запроса в миллисекундах. В новых версиях sysstat есть отдельные r_await и w_await. Резкий рост w_await обычно указывает на проблему записи: журналирование, fsync, dirty pages, медленное хранилище, насыщение RAID или сетевого диска.

4) aqu-sz (avgqu-sz) — средняя длина очереди запросов к устройству. Если очередь стабильно растёт, приложение генерирует больше I/O, чем устройство успевает обслужить.

5) %util — процент времени, когда устройство было занято обработкой запросов. Значения около 100% часто означают насыщение, но не всегда: для NVMe и многоканальных устройств %util может быть высоким при ещё не исчерпанном запасе по параллелизму, а для старых HDD почти постоянные 100% — обычно плохой знак.

6) rareq-sz и wareq-sz — средний размер операций чтения и записи. Мелкие случайные операции и крупные последовательные потоки нагружают диск по-разному: база данных с множеством мелких sync-записей может страдать при меньшем MB/s, чем процесс копирования большого файла.

7) %iowait в CPU-блоке — доля времени, когда CPU простаивал в ожидании I/O. Это не «процент загрузки диска»: высокий iowait говорит, что часть задач ждёт диск, а низкий — не гарантирует отсутствия проблемы, если CPU занят другой работой.

8) svctm — устаревшее поле, на которое в современных системах лучше не опираться (в ряде версий оно скрыто или считается недостаточно надёжным). Ориентируйтесь на await, r_await, w_await, aqu-sz, %util и реальные симптомы приложения.

Абсолютных универсальных порогов нет — сравнивайте метрики с нормальным состоянием конкретного сервера. Для HDD, SATA SSD, NVMe, сетевого блочного устройства и облачного диска «нормальная задержка» будет разной. Подробно про измерение задержек и поиск узких мест: I/O latency: как измерять и находить узкие места в дисковой подсистеме.

Практические сценарии с iostat

iostat отвечает не на вопрос «кто виноват», а на вопрос «что происходит с устройством». Начинать диагностику удобно с нескольких типовых шаблонов.

1) Высокий %util, высокий await, растёт aqu-sz — устройство насыщено, запросы стоят в очереди. Дальше ищите источник нагрузки через iotop, логи, метрики базы и расписание фоновых задач.

2) Высокий w_await, но умеренный wkB/s — много мелких или синхронных записей. Частые причины: интенсивное логирование, база данных с большим числом транзакций, fsync на каждый запрос, очередь сообщений, запись временных файлов.

3) Высокий rkB/s, крупный rareq-sz, умеренный r/s — вероятно, идёт последовательное чтение: бэкап, скан таблицы, индексация, антивирусная проверка, обработка медиафайлов.

4) Высокий r/s или w/s, но небольшой MB/s — много мелких операций. Для HDD это особенно болезненно, потому что случайный доступ дорогой; для SSD и NVMe ситуация лучше, но задержки всё равно могут расти при насыщении очереди.

5) Высокий iowait, но диск по iostat не выглядит загруженным — проверьте другие устройства, сетевые файловые системы, swap, контроллер, виртуализацию, а также нужный интервал и хост. В контейнерной среде нагрузка может быть видна иначе на хосте и внутри контейнера.

6) Один диск загружен, остальные простаивают — проблема может быть в неравномерном размещении данных: например, база, логи и временные файлы лежат на одном томе, а второй диск почти не используется.

7) После запуска бэкапа растёт latency приложения — проверьте wkB/s, rkB/s, await и расписание задач. Если бэкап нужен, но мешает продакшену, используйте ограничение скорости, ionice, отдельный диск, реплику или окно низкой нагрузки. Для контекста по резервному копированию пригодятся материалы про виды бэкапов и rsync с cron.

Если вы меняете настройки дисковой подсистемы, не ограничивайтесь одним замером. Сравните поведение до и после: задержки, throughput, нагрузку приложения, ошибки и пользовательскую latency. Про роль планировщика I/O есть отдельный материал: как работает Linux I/O scheduler.

iotop: какой процесс грузит диск

Когда iostat показал проблему на устройстве, следующий вопрос — какой процесс создаёт I/O. Для этого используют iotop.

Базовый запуск:

sudo iotop

Интерфейс похож на top: список процессов обновляется в реальном времени. Основные колонки:

• DISK READ — текущая скорость чтения процесса;
• DISK WRITE — текущая скорость записи;
• SWAPIN — доля времени, связанная с ожиданием swap-in;
• IO> или IO% — доля времени, когда процесс ждал I/O;
• COMMAND — команда процесса.

Полезные режимы:

1) Только активные процессы: sudo iotop -o. Без этого экран может быть забит процессами с нулевой текущей активностью.

2) Группировка по процессам, а не потокам: sudo iotop -P. Это удобнее для первичного анализа: видно процесс целиком, а не десятки потоков одного сервиса.

3) Накопительный режим: sudo iotop -a. Показывает суммарный объём чтения и записи за время работы iotop — полезно, если нагрузка идёт короткими всплесками: текущий момент можно пропустить, а накопительный счётчик всё равно покажет виновника.

4) Только активные процессы плюс накопление: sudo iotop -oPa. Один из самых удобных вариантов для расследования.

5) Batch-режим для логирования: sudo iotop -b -o -n 20 -d 1. Команда выведет 20 итераций с интервалом 1 секунда — это можно сохранить в файл во время инцидента.

Пример вывода:

Total DISK READ: 0.00 B/s | Total DISK WRITE: 86.42 M/s
TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>  COMMAND
1842 be/4  postgres 0.00 B/s   52.10 M/s   0.00 %  71%  postgres: checkpointer
2310 be/4  root     0.00 B/s   28.40 M/s   0.00 %  48%  rsync -a /data /backup
912  be/4  syslog   0.00 B/s    3.20 M/s   0.00 %  12%  rsyslogd

Здесь видно, что активная запись идёт от PostgreSQL и rsync. Это ещё не означает, что они «плохие»: возможно, checkpointer делает нормальную работу, а rsync запущен по расписанию. Но теперь есть конкретные процессы для дальнейшей проверки.

Ограничения iotop и частые ловушки

iotop удобен, но его легко неправильно интерпретировать.

1) Page cache скрывает часть картины — чтение может обслуживаться из кэша памяти, поэтому процесс логически активно читает данные, а физического I/O почти нет. И наоборот: приложение давно записало данные, а фактическая запись на диск выполняется позже процессами ядра.

2) Запись может отображаться не там, где вы ждёте — dirty pages сбрасываются фоновыми механизмами ядра. Вы можете видеть активность jbd2, flush или kworker, хотя исходная причина — другое приложение, которое генерирует записи.

3) IO% — не процент использования диска — это показатель ожидания I/O для процесса. Высокий IO% у процесса говорит, что он много ждёт дисковую подсистему, но не обязательно сам генерирует максимальный throughput.

4) В контейнерах видимость ограничена — внутри контейнера можно не увидеть полную картину по хосту. Если сайт работает в Docker, полезно смотреть нагрузку и из контейнера, и на хосте. Базовые команды Docker разобраны отдельно: основные команды Docker.

5) Короткие пики легко пропустить — если процесс пишет 500 МБ за несколько секунд, при ручном запуске можно попасть уже после события. Помогают накопительный режим iotop -a, системные метрики, atop, sar и постоянный мониторинг.

6) Не вся «дисковая» проблема находится на локальном диске — NFS, сетевые блочные устройства, облачные volume, SAN и распределённые файловые системы могут давать задержки, которые на уровне приложения выглядят как медленный диск. Тогда нужны метрики сети, хранилища и гипервизора.

Для более широкого взгляда на ресурсы сервера можно использовать atop и glances: они показывают CPU, память, диск, сеть и процессы в одном интерфейсе.

Типовые причины высокой I/O-нагрузки

После того как iostat показал насыщение диска, а iotop указал процессы, нужно понять причину. Частые варианты:

1) База данных — checkpoint, vacuum, autovacuum, массовые обновления, отсутствие индексов, большие сортировки на диск, временные таблицы, репликация, дампы. Если база — ключевой компонент сервиса, стоит отдельно собирать её метрики: latency запросов, locks, buffer cache, checkpoints, temporary files. Смежный материал: мониторинг производительности PostgreSQL и MySQL.

2) Логи — слишком подробный уровень логирования, запись каждого запроса, stack trace в цикле, большие JSON-логи, синхронная запись. Ротация тоже может дать пик, особенно при сжатии больших файлов.

3) Бэкапы и синхронизация — rsync, tar, gzip, mysqldump, pg_dump, snapshot-агенты. Проблема не в самом факте бэкапа, а в конкуренции за диск с рабочей нагрузкой.

4) Swap — если памяти не хватает, система начинает активно читать и писать страницы на диск. В iotop это видно по SWAPIN, в vmstat — по активности si и so. Это уже не просто дисковая проблема, а нехватка памяти или утечка.

5) Очереди и брокеры сообщений — RabbitMQ, Kafka, Redis с AOF, локальные очереди задач. Такие системы могут активно писать журналы, сегменты, снапшоты и временные данные.

6) Контейнерные overlay-файловые системы — большое количество мелких файлов, запись логов контейнеров, сборка образов, распаковка слоёв. Иногда проблема решается переносом данных на volume, настройкой лог-драйвера или ограничением ротации.

7) Файловые операции приложения — загрузка изображений, генерация PDF, обработка видео, распаковка архивов, временные файлы. Если это часть пользовательского запроса, дисковая задержка напрямую превращается в HTTP latency.

8) Антивирусы, индексаторы, агенты мониторинга — редко главные виновники, но на слабых дисках и при больших деревьях файлов могут создавать заметную фоновую нагрузку.

Чтобы не лечить симптом, связывайте процесс из iotop с бизнес-операцией: какой endpoint, cron-задача, миграция, бэкап, релиз или пользовательский сценарий его породили.

Как действовать во время инцидента

Когда сайт уже медленно отвечает, порядок действий важнее идеальной глубины анализа. Хороший минимальный сценарий:

1) Зафиксируйте внешний симптом — время начала, тип ошибки, какие URL или API затронуты, есть ли проблема у всех пользователей. Если используется uptime-мониторинг, отметьте время алерта и регион проверки. У Statuser, например, проверка идёт с заданным интервалом, а уведомление о сбое помогает быстро привязать инцидент ко времени.

2) Снимите состояние устройств:

iostat -xz -y 1 10

Сохраните вывод — потом он пригодится для постмортема.

3) Найдите процессы:

sudo iotop -oPa

Если нагрузка скачет, подержите утилиту открытой хотя бы несколько минут или используйте batch-режим.

4) Проверьте системные признаки — free -h, vmstat 1, df -h, df -i, journalctl, логи приложения, метрики базы. Диск может быть не только медленным, но и заполненным. Для анализа занятого места пригодится ncdu.

5) Снизьте давление на диск — остановите необязательный бэкап, уменьшите параллелизм задачи, временно снизьте логирование, перенесите тяжёлую операцию, включите rate limit на фоновые воркеры. Не убивайте процесс базы или системные процессы без понимания последствий.

6) После стабилизации найдите корень проблемы — расписание, релиз, рост трафика, неудачный запрос, заполнение кэша, новые логи, изменение настроек хранилища. Разовый kill редко решает проблему надолго.

Если такие инциденты повторяются, переводите диагностику в метрики: latency диска, IOPS, throughput, queue depth, использование файловых систем, slow queries, latency приложения и HTTP-ошибки. Базовый подход к серверному мониторингу разобран в статье про Prometheus и Grafana.

FAQ

Что лучше использовать: iostat или iotop?
Они отвечают на разные вопросы. iostat показывает состояние устройств: задержки, очередь, throughput, утилизацию. iotop показывает процессы, которые читают или пишут на диск. Обычно сначала запускают iostat, затем iotop.

Почему iostat показывает высокий %util, но сайт работает нормально?
Для быстрых SSD и NVMe высокий %util сам по себе не всегда означает проблему. Смотрите вместе await, aqu-sz, latency приложения, ошибки и пользовательские симптомы. Если задержки низкие и сервис отвечает стабильно, это может быть нормальная нагрузка.

Почему iotop не показывает виновника, хотя диск загружен?
Причина может быть в page cache, фоновой записи ядра, контейнерах, сетевом хранилище или коротких пиках. Используйте iotop -a, смотрите хостовую систему, проверяйте iostat, vmstat, логи и исторические метрики.

Можно ли запускать iostat и iotop в продакшене?
Да, обычно они безопасны для разовой диагностики. iostat почти не создаёт нагрузки. iotop тоже подходит для ручного анализа, но не стоит запускать его постоянно как замену нормальному сбору метрик.