iostat и iotop: диагностика узких мест в хранилище Linux

Когда сервер Linux работает медленно, одним из первых мест, на которые следует обратить внимание, является хранилище. iostat показывает, перегружен ли диск; iotop показывает, какой процесс вызывает нагрузку. Используемые вместе, они дают ответы на два важных вопроса: действительно ли диск является узким местом, и если да, то что его перегружает? В этой статье рассматриваются установка, интерпретация вывода (в том числе, где на современном оборудовании находится показатель iostat %util на современном оборудовании), а также рабочий процесс, позволяющий перейти от симптома к устранению проблемы.

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

iostat входит в пакет sysstat; iotop поставляется отдельно. Установите оба:

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

В Ubuntu sysstat поставляется в отключенном состоянии. Чтобы собрать фоновые данные для последующего анализа с помощью sar, отредактируйте /etc/default/sysstat, установите ENABLED="true"и перезапустите службу:

sudo systemctl restart sysstat

iotop должен запускаться от имени root. В RHEL 9 и более поздних версиях учет задержек по умолчанию отключен, что оставляет IO и SWAPIN остаются пустыми. Включите его с помощью:

echo 1 | sudo tee /proc/sys/kernel/task_delayacct

Добавьте kernel.task_delayacct = 1 в /etc/sysctl.conf , чтобы настройка сохранялась после перезагрузки.

Чтение вывода iostat

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

iostat -xz 2

Флаг -x флаг добавляет расширенную статистику, -z скрывает неактивные устройства, а 2 обновляет данные каждые две секунды. Важные столбцы:

• await: среднее время в миллисекундах на выполнение запроса ввода-вывода, включая время ожидания в очереди. Самый важный показатель, когда пользователи жалуются на медленную работу.
• r/s и w/s: IOPS чтения и записи. В сочетании с rkB/s и wkB/s эти показатели позволяют определить, является ли ваша рабочая нагрузка случайной (высокий показатель IOPS, низкая пропускная способность) или последовательной (низкий показатель IOPS, высокая пропускная способность).
• aqu-sz: средняя глубина очереди. Для жестких дисков любое значение, стабильно превышающее 1, означает, что диск не справляется.
• %util: процент времени, в течение которого на устройстве выполнялась хотя бы одна операция ввода-вывода. Полезно для жестких дисков, вводит в заблуждение для NVMe (см. ниже).

Краткое справочное руководство по пороговым значениям:

Там, где находится %util

%util — это показатель, к которому большинство людей обращается в первую очередь, и в случае с NVMe он активно вводит в заблуждение. Ядро считает %util «любой вход-выход, выполняющийся в данный момент», что подходит для вращающегося диска, обрабатывающего по одному запросу за раз, но бессмысленно для устройств NVMe, которые обрабатывают тысячи запросов параллельно через аппаратные очереди. Диск NVMe может показывать 100% %util , работая на 5% от своей реальной мощности.

В случае NVMe доверяйте r_await, w_await, а aqu-sz вместо этого. Если r_await остается ниже 1 мс, а глубина очереди значительно ниже глубины аппаратной очереди устройства (часто 1024 или выше), диск на самом деле не перегружен, независимо от того, что %util говорит.

Для быстрого просмотра данных NVMe в МБ/с, а не в кБ/с:

iostat -xm 1

Для долгосрочного сбора данных вы можете позже сопоставить их с журналами приложений:

iostat -x -t 5 720 > /var/log/iostat.log

Это обеспечивает выборку каждые 5 секунд в течение часа. sar Из того же пакета sysstat вы получите эквивалентные данные с постоянным хранением истории, и это лучший выбор для непрерывного мониторинга.

Подтверждение с помощью CPU iowait

Если iostat показывает нагрузку на хранилище, сверьте данные со столбцом %iowait столбцом в сводке по ЦП в верхней части того же вывода. Устойчивое %iowait значения выше 15–20% в сочетании с высоким показателем await подтверждает, что узким местом является хранилище. Если %iowait высоко, но await выглядит нормально, запустите vmstat 1 и проверьте si и so . Не нулевая активность подкачки означает, что вы ограничены памятью, а дисковый трафик связан с подкачкой, а не с вводом-выводом приложения.

Чтение вывода iotop

Как только iostat подтвердит наличие узкого места в хранении данных, iotop укажет, какой процесс за это отвечает. Начните с:

sudo iotop -o

Флаг -o скрывает простаивающие процессы, оставляя только те, которые активно выполняют ввод-вывод. Колонки, на которые следует обратить внимание:

• DISK READ / DISK WRITE: пропускная способность в реальном времени для каждого процесса. Позволяет выявить явных «тяжеловесов».
• IO: процент времени, в течение которого процесс заблокирован на вводе-выводе. Процесс, записывающий всего 50 кБ/с, может показывать 99% IO, если он выполняет мелкие синхронные fsync() вызовы. Этот столбец важнее, чем просто пропускная способность.
• SWAPIN: процент времени, затрачиваемого на ожидание страниц подкачки. Ненулевое значение здесь означает, что система использует подкачку, и ваша «проблема с хранением» на самом деле является проблемой с памятью.

Для многопоточных приложений (MySQL, PostgreSQL, Java-нагрузки) объедините потоки обратно в процессы с помощью -P, и сложите -a для накопления итоговых значений с момента запуска iotop:

sudo iotop -oPa

Флаг -a — это хитрость для отслеживания пиковых нагрузок, таких как задания резервного копирования, которые выполняются лишь в течение нескольких секунд за раз и которые в противном случае было бы трудно заметить в режиме реального времени.

Для автоматической регистрации событий в ночное время, когда никто не наблюдает:

sudo iotop -botqq -d 10 > /var/log/iotop.log

Это записывает неинтерактивный снимок каждые 10 секунд. Совместите это с временными метками из ваших заданий резервного копирования или cron, чтобы найти виновника после того, как все произошло.

Рабочий процесс диагностики

Большинство исследований дискового ввода-вывода следуют одному и тому же пути:

1. iostat -xz 2 чтобы подтвердить, что диск действительно является узким местом. Посмотрите await, aqu-szи %iowait. Если эти показатели в норме, проблема не в хранилище, и вам следует искать причину совсем в другом месте.
2. iotop -oPa чтобы найти процесс, создающий нагрузку. Следите за столбцом ввода-вывода больше, чем за столбцом пропускной способности. Чаще всего виновниками являются программы, выполняющие множество мелких синхронных записей, а не те, которые перемещают наибольший объем данных.
3. lsof -p <pid> чтобы увидеть, с какими файлами работает этот процесс. Обычно это сразу позволяет определить тип рабочей нагрузки: журнал опережающей записи базы данных, файл журнала приложения, точка монтирования резервной копии, временный файл.

Два паттерна, о которых стоит знать.

Если вы видите потоки ядра, такие как jbd2/... (журнал ext4) или txg_sync (ZFS) в верхней части списка записывающих процессов iotop, они реагируют на записи от других процессов, а не инициируют их. Процесс в пользовательском пространстве, вызывающий трафик журнала, является фактической причиной; продолжайте поиск.

На VPS высокий await при низком %util — классический признак «шумного соседа». Другой арендатор монополизирует общее хранилище, и ваши операции ввода-вывода стоят в очереди на стороне гипервизора, а не на вашем виртуальном диске. Вы можете подтвердить, но не исправить это изнутри гостевой системы; решением будет либо обратиться к провайдеру, либо перейти на сервер с изолированным хранилищем.

Устранение распространенных узких мест ввода-вывода

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

Снизьте приоритет некритического ввода-вывода. ionice помещает процесс в класс планирования «idle», где он использует пропускную способность диска только тогда, когда она не нужна никому другому:

ionice -c 3 -p <pid>
sudo ionice -c 3 rsync -a /data /backup

Первая форма изменяет запущенный процесс; вторая запускает новый, уже находящийся в классе простоя. В iotop вы можете интерактивно изменить приоритет запущенного процесса, нажав i.

Переместите «горячие» рабочие нагрузки на более быстрое хранилище. Если iostat показывает, что диск SATA перегружен записями в базу данных, а в том же сервере есть простаивающий NVMe, переместите каталог данных базы данных. Разница в IOPS на несколько порядков делает это самым эффективным из доступных решений.

Установите правильный планировщик ввода-вывода. Современные ядра по умолчанию настроены достаточно разумно, но это стоит проверить. Для NVMe и SSD установите планировщик на none. Устройство обрабатывает очереди на аппаратном уровне лучше, чем ядро:

echo none > /sys/block/nvme0n1/queue/scheduler

Для жестких дисков, обрабатывающих смешанные рабочие нагрузки, mq-deadline обычно выбирают

Монтируйте с параметром noatime. По умолчанию каждое чтение обновляет метку времени последнего доступа к файлу, что приводит к записи при каждом чтении. В файловых системах с интенсивным чтением это излишний ввод-вывод. Добавьте noatime в опции монтирования в /etc/fstab:

UUID=... /data ext4 defaults,noatime 0 2

Настройте writeback для импульсных записей. На серверах с большим объемом ОЗУ по умолчанию пороги грязных страниц позволяют кэшу страниц накапливать гигабайты незаписанных данных, а затем сбрасывать их одним большим блоком. Уменьшите пороги в /etc/sysctl.conf , чтобы сгладить это:

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

Сам диск обычно не является проблемой. Когда iostat показывает высокий показатель IOPS и низкую пропускную способность, рабочая нагрузка выполняет произвольный ввод-вывод данных, которые могли бы быть последовательными, или выполняет множество мелких записей, которые можно было бы объединить в пакеты. Проанализируйте приложение, прежде чем винить аппаратное обеспечение.

Если вы выполняете рабочие нагрузки с интенсивным использованием хранилища на сервере, где сеть может работать быстрее диска, выделенные серверы FDC на базе NVMe предоставляют вам резерв мощности для эффективного применения описанной выше настройки.