Как оценить загрузку жесткого диска в Linux

Оценка загрузки жесткого диска в Linux

Оценка загрузки жесткого диска (или дисковых подсистем ввода-вывода) — критическая задача для DevOps Engineer. Недостаточный IOPS (Input/Output Operations Per Second) или высокая latency (задержка) часто становятся «узким местом» производительности приложений, особенно в средах с высокой нагрузкой (базы данных, хранилища, виртуализация). В Linux существует богатый арсенал инструментов для мониторинга и диагностики.

Ключевые метрики для оценки

Перед выбором инструмента важно понимать, что именно мы измеряем:

• Утилизация диска (%util) — процент времени, когда устройство было занято обработкой запросов. Значение, близкое к 100%, явно указывает на перегрузку.
• Задержка (Latency) — время, за которое завершается операция ввода-вывода. Измеряется в миллисекундах (await — среднее время для запросов, включая время в очереди; svctm — среднее время обслуживания самого устройства).
• Пропускная способность (Throughput) — объем данных, читаемых или записываемых в секунду (r/s, w/s — количество операций; rkB/s, wkB/s — килобайты в секунду).
• Длина очереди (Queue Length) — среднее количество невыполненных запросов в очереди (avgqu-sz).

Основные инструменты командной строки

1. iostat (из пакета sysstat) — основной инструмент

Показывает статистику использования CPU и устройств хранения. Самый информативный инструмент для первичного анализа.

# Базовая команда: показывать отчет каждые 2 секунды
iostat -dx 2

# Расширенный вывод с группировкой по всем устройствам, включая LVM и разделы
iostat -dxm 2

# Вывод только для конкретного устройства (например, sda)
iostat -dx sda 2

Как читать вывод для устройства sda:

Device            r/s     w/s     rkB/s     wkB/s   avgqu-sz   await r_await w_await  %util
sda              5.20    0.40    100.00      8.00       0.05    8.00    7.50   15.00    1.20

• r/s, w/s > 100-200 на HDD часто говорит о высокой нагрузке.
• await > 20-30 мс на HDD или > 5-10 мс на SSD — тревожный признак.
• %util > 70-80% — устройство работает на пределе.

2. iotop — аналог top для дискового IO

Показывает, какие именно процессы создают нагрузку на диск, в реальном времени. Незаменим для выявления «виновника».

# Запуск с сортировкой по общему объему IO
sudo iotop -o

# Запуск с накопленной статистикой
sudo iotop -a

В выводе видно PID, пользователя, скорость чтения/записи и общий объем на процесс.

3. vmstat — общая статистика системы

Дает быстрый срез, включая блокирующие операции ввода-вывода (bi, bo).

vmstat 2

Строка io:

• bi — blocks received from a block device (blocks/s).
• bo — blocks sent to a block device (blocks/s). Резкий рост этих значений указывает на активную дисковую работу.

4. dstat — универсальный и гибкий монитор

Комбинирует возможности vmstat, iostat, netstat и других. Удобен для одновременного наблюдения за диском, сетью и CPU.

# Мониторинг диска, CPU и сети
dstat -cd --disk-util

# Показать IOPS и пропускную способность для всех дисков
dstat -d --disk-util

5. pidstat — детальная статистика по процессам

Еще один способ получить IO-статистику на уровне процессов.

# Статистика по дисковому вводу-выводу для всех процессов каждые 2 секунды
pidstat -d 2

6. fio и bonnie++ — для синтетического тестирования и бенчмарков

Используются для оценки максимальных возможностей диска (IOPS, latency, throughput) под контролируемой нагрузкой (последовательное/случайное чтение/запись, разный блок, глубина очереди). Важно: Эти инструменты создают реальную нагрузку и могут повредить данные, используйте только на тестовых системах или неиспользуемых дисках.

Пример простого теста fio на случайное чтение:

fio --name=randread --ioengine=libaio --iodepth=16 --rw=randread --bs=4k --direct=1 --size=1G --numjobs=4 --runtime=60 --group_reporting

Практический подход DevOps

1. Базовая диагностика: При жалобах на «тормоза» начинаю с iostat -dx 2 для оценки общей утилизации и задержек. Параллельно запускаю iotop для поиска проблемных процессов.
2. Глубокая аналитика: Если %util высокий, а await большой, смотрю avgqu-sz. Большая очередь подтверждает, что устройство не справляется с нагрузкой.
3. Поиск узкого места: Определяю тип нагрузки: много мелких случайных операций (высокий r/s/w/s, низкий rkB/s/wkB/s) характерен для СУБД — нужно смотреть в сторону увеличения IOPS (переход на SSD, RAID 10). Большие последовательные операции (низкий r/s, высокий rkB/s) — задача для пропускной способности (RAID 0/5/6, более быстрые диски).
4. Мониторинг и алертинг: В продакшене настраиваю сбор метрик (например, через node_exporter для Prometheus) по ключевым показателям: disk_utilization, disk_await, disk_iops. На основе этих данных строятся дашборды в Grafana и настраиваются алерты (например, %util > 80% или await > 50ms в течение 5 минут).

Таким образом, оценка загрузки диска — это не разовая команда, а комплексный анализ метрик с помощью набора инструментов, позволяющий не только констатировать факт проблемы, но и понять ее первопричину и спланировать оптимизацию инфраструктуры.