Устранение высокой задержки дискового ввода-вывода: пошаговое руководство по Linux

Высокая задержка дискового ввода-вывода имеет очень специфическое ощущение. SSH всё ещё подключается, процессор не загружен на 100%, но каждая команда, которая касается файлов, зависает на мгновение. Веб-приложение приостанавливается при записи сессий. Запрос к базе данных, который обычно выполняется быстро, начинает ждать хранилище. Машина выглядит живой, но кажется, что она идёт по грязи.

Хитрость в том, чтобы избегать догадок. «Диск медленный» может означать насыщенное блочное устройство, thrashing подкачки, выходящий из строя диск, шумную задачу резервного копирования, перегруженный сетевой том или базу данных, выполняющую случайные чтения из-за отсутствия индекса. Один и тот же симптом может быть вызван совершенно разными причинами.

Понимание метрик дискового ввода-вывода

Прежде чем погружаться в устранение неполадок, важно понять ключевые метрики, указывающие на проблему с вводом-выводом. Высокая задержка является основным симптомом, но нам нужны дополнительные точки данных, чтобы подтвердить серьёзность проблемы и её источник.

Ключевые индикаторы конкуренции за ввод-вывод

• Высокая задержка (await): Среднее время в миллисекундах для завершения запросов ввода-вывода. Включает время ожидания в очереди и время обслуживания. Что считается «высоким», зависит от хранилища и рабочей нагрузки; сравнивайте с нормальным базовым уровнем системы, когда это возможно.
• Высокая утилизация (%util): Когда эта метрика приближается к 100%, устройство насыщено и не может эффективно обрабатывать дальнейшие запросы.
• Высокое ожидание в очереди (avgqu-sz): Большой средний размер очереди означает, что многие процессы ждут, пока диск освободится.

Шаг 1: Первоначальная проверка здоровья системы с помощью iostat

Утилита iostat (часть пакета sysstat) является краеугольным камнем для мониторинга использования устройств и статистики производительности. Она предоставляет исторические и текущие данные о загрузке ЦП и вводе-выводе устройств.

Чтобы получить текущий подсчёт производительности ввода-вывода, запустите iostat с интервалом (например, каждые 2 секунды):

sudo iostat -dxm 2

Анализ вывода iostat -dxm

Сосредоточьтесь на столбцах статистики устройств (флаг x):

Столбец	Описание	Значение высокого значения
r/s, w/s	Чтений/записей в секунду (IOPS)	Высокие значения указывают на высокий спрос на пропускную способность.
rkB/s, wkB/s	Килобайт прочитано/записано в секунду	Измеряет объём пропускной способности.
await	Среднее время ожидания (мс) для запросов ввода-вывода (время обслуживания + время в очереди)	Основной индикатор высокой задержки.
%util	Процент времени, когда устройство было занято обслуживанием запросов	Близко к 100% указывает на насыщение.

Пример сценария: Если /dev/sda показывает время await 150 мс и %util 98%, вы подтвердили серьёзное узкое место ввода-вывода на этом диске.

Совет: Используйте флаг -x для расширенной статистики и -m для отчёта в мегабайтах, что часто понятнее, чем килобайты (-k).

Шаг 2: Определение процесса-виновника с помощью iotop

Как только iostat подтвердит высокую задержку на конкретном устройстве (например, /dev/sda), следующим важным шагом будет определение того, какой процесс генерирует эту нагрузку. Утилита iotop, которая отражает функциональность команды top, но фокусируется на активности ввода-вывода, здесь необходима.

Если iotop не установлен, сначала установите его:

# Debian/Ubuntu
sudo apt update && sudo apt install iotop

# RHEL/CentOS/Fedora
sudo yum install iotop  # или dnf install iotop

Запустите iotop с правами root, показывая только процессы, активно выполняющие ввод-вывод:

sudo iotop -oP

• -o: Показывать только процессы, активно выполняющие ввод-вывод.
• -P: Показывать процессы, а не отдельные потоки.

Изучите вывод, обращая внимание на столбцы IO_READ и IO_WRITE. Процессы, перечисленные вверху, потребляют наибольшую пропускную способность диска. Обычные виновники включают серверы баз данных (MySQL, PostgreSQL), утилиты резервного копирования, скрипты ротации журналов или системы, агрессивно записывающие в пространство подкачки.

Интерпретация вывода iotop

iotop отображает общее использование диска для каждого процесса. Если вы видите, что одно приложение доминирует в использовании диска (например, скрипт резервного копирования работает со скоростью 50 МБ/с, в то время как задержка растёт), вы нашли непосредственную причину.

Шаг 3: Глубокое погружение с помощью pidstat

В то время как iotop показывает совокупный ввод-вывод на процесс, pidstat может предоставить подробный исторический контекст операций ввода-вывода, инициированных конкретными PID, что полезно для долго выполняющихся или периодических проблем.

Чтобы отслеживать статистику ввода-вывода (чтение и запись блоков) для всех процессов каждые 5 секунд в течение 5 итераций:

sudo pidstat -d 5 5

Ключевые метрики в выводе -d включают:

• kB_rd/s: Количество данных, прочитанных с диска в секунду задачей.
• kB_wr/s: Количество данных, записанных на диск в секунду задачей.
• kB_ccwr/s: Количество данных, записанных в пространство подкачки (c=отменённая/зафиксированная запись).

Если чтения и записи для одного и того же процесса увеличиваются всякий раз, когда пользователи сообщают о паузах, у вас есть полезная зацепка. pidstat особенно полезен, когда iotop показывает короткий всплеск, а затем очищается до того, как вы успеваете его прочитать.

Шаг 4: Диагностика thrashing памяти (использование подкачки)

Высокая активность подкачки часто проявляется как высокая задержка дискового ввода-вывода, потому что система вынуждена использовать медленный физический диск в качестве виртуальной оперативной памяти. Используйте команду free, чтобы проверить давление на память:

free -h

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

Решение для thrashing:

1. Определите процессы, потребляющие много памяти, с помощью top или htop.
2. Увеличьте оперативную память системы, если это возможно.
3. Настройте приложения на использование меньшего объёма памяти.

Также проверьте vmstat, пока происходит проблема:

vmstat 1

Столбцы si и so показывают активность подкачки (swap-in и swap-out). Периодические ненулевые значения не являются автоматически кризисом. Устойчивая активность, пока система медленная, является более сильным сигналом. Столбец ЦП wa также полезен: высокий I/O wait означает, что задачи тратят время на блокировку хранилища, а не на выполнение на ЦП.

Шаг 5: Сопоставление устройства с файловой системой

iostat сообщает о блочных устройствах: sda, nvme0n1, dm-0, md0 и так далее. Журналы вашего приложения обычно упоминают пути: /var/lib/mysql, /var/log, /home, /data. Прежде чем обвинять неправильный диск, сопоставьте путь с устройством.

df -hT /var/lib/mysql
findmnt /var/lib/mysql
lsblk -f

Это важно на хостах с LVM, программным RAID, облачными томами или отдельными точками монтирования. Вы можете увидеть высокую задержку на dm-0, но фактическим базовым устройством может быть том EBS, массив mdraid или зашифрованное устройство-маппер. Если занятая файловая система находится в сетевом хранилище, локальные дисковые инструменты рассказывают только часть истории. Вам также потребуется проверить NFS, iSCSI, метрики облачных томов или устройство хранения.

Шаг 6: Поиск подсказок ядра и оборудования

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

dmesg -T | egrep -i 'error|reset|timeout|nvme|scsi|blk_update|i/o error'
journalctl -k --since "30 minutes ago"

Для физических дисков могут быть полезны данные SMART:

sudo smartctl -a /dev/sda

Для устройств NVMe:

sudo nvme smart-log /dev/nvme0

Не переоценивайте одно поле SMART изолированно. Разные поставщики предоставляют разные счётчики. Но переназначенные сектора, ошибки носителя, повторяющиеся тайм-ауты команд или ошибки ввода-вывода ядра заслуживают немедленного внимания. Если диск поддерживает производственную базу данных, перестаньте рассматривать это как упражнение по настройке и переходите к избыточности, отказоустойчивости или замене.

Шаг 7: Разделение проблем пропускной способности и задержки

Два инцидента могут показывать «медленный диск», требуя разных исправлений.

Последовательное резервное копирование может давать высокие wkB/s и высокий %util. Это проблема пропускной способности. Может помочь ограничение резервного копирования, перенос его на непиковое время, использование инкрементальных резервных копий или запись на другой том.

База данных с отсутствующими индексами может показывать скромную пропускную способность, но болезненный await, много маленьких чтений и заметные пользователем задержки запросов. Это часто проблема случайного ввода-вывода и формы запроса. Увеличение пропускной способности может помочь меньше, чем добавление правильного индекса или уменьшение рабочего набора.

Используйте эту краткую справку:

• Высокие rkB/s или wkB/s, высокий %util, очевидная большая задача: ищите массовые чтения/записи.
• Высокие r/s или w/s, высокий await, меньшая пропускная способность: ищите много маленьких случайных операций.
• Высокая активность подкачки, высокий wa, мало свободной памяти: рассматривайте давление памяти как коренную причину.
• Высокая задержка с ошибками ядра: рассматривайте здоровье хранилища как коренную причину.

Шаг 8: Проверка контекста на уровне приложения

Системные инструменты говорят вам, кто касается хранилища. Они не всегда говорят вам, почему.

Для баз данных проверьте журналы медленных запросов и метрики буфера/кэша. Процесс MySQL на вершине iotop может быть нормальным во время резервного копирования, плохим во время пикового трафика или ожидаемым после перезапуска, пока пул буферов холодный. PostgreSQL может выполнять autovacuum, записи контрольных точек или запрос, который выгружается на диск. MongoDB может выполнять уплотнение, построение индексов или чтение рабочего набора, который больше не помещается в оперативную память.

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

Для контейнеров помните, что шумный процесс может появляться под containerd, dockerd или overlay-файловой системой. Используйте также инструменты уровня контейнеров:

docker stats
docker ps --format 'table {{.ID}}\t{{.Names}}\t{{.Status}}'

На узлах Kubernetes сравнивайте ввод-вывод на уровне хоста с размещением подов. Один под, активно записывающий в emptyDir, hostPath или локальный постоянный том, может сделать несвязанные поды на том же узле нездоровыми.

Распространённые причины и стратегии исправления

После определения источника примените соответствующее исправление:

1. Резервное копирование или задачи обслуживания

Симптом: Высокая утилизация ввода-вывода, совпадающая с запланированными задачами (например, cron-задачи). Исправление: Перенесите большие задачи ввода-вывода, ограничьте их, если утилита это поддерживает, или переместите временный вывод на другой том. Например, rsync --bwlimit, ionice и собственные ограничения резервного копирования баз данных могут уменьшить радиус поражения.

2. Неэффективные запросы к базе данных

Симптом: Процессы базы данных (например, mysqld) являются главными потребителями в iotop. Исправление: Оптимизируйте плохо индексированные запросы, которые вызывают полное сканирование таблиц, приводящее к массовым случайным чтениям.

3. Чрезмерное ведение журналов

Симптом: Процессы ведения журналов приложения или системы записывают огромные объёмы данных. Исправление: Проверьте уровни ведения журналов приложения. Рассмотрите возможность буферизации журналов или использования удалённого решения для ведения журналов (например, Syslog или стек ELK) для уменьшения локальных дисковых записей.

4. Отказ диска или неправильная конфигурация

Симптом: Чрезвычайно высокое время await, которое не коррелирует с высокой пропускной способностью, или странные шаблоны чтения/записи. Это может указывать на отказ оборудования или неправильную конфигурацию RAID. Исправление: Проверьте данные SMART (smartctl) на предмет здоровья диска. При использовании RAID проверьте состояние массива.

5. Файловая система или параметры монтирования

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

Исправление: Проверьте тип файловой системы, параметры монтирования, использование inode и поведение журнала. Полная файловая система, исчерпанные inode или почти полный тонко-распределённый том могут выглядеть как проблема задержки ввода-вывода со стороны приложения.

df -h
df -ih
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

Если использование inode составляет 100%, удаление одного гигантского файла не поможет. Вам нужно удалить много маленьких файлов или переместить эту рабочую нагрузку на макет файловой системы, предназначенный для этого.

Лучшие практики для упреждающего мониторинга

Предотвращение узких мест ввода-вывода лучше, чем их реактивное исправление. Внедрите непрерывный мониторинг:

• Установите оповещения: Настройте инструменты мониторинга для оповещения об устойчивых изменениях задержки диска, глубины очереди, I/O wait, заполненности файловой системы и счётчиков ошибок. Используйте пороговые значения, соответствующие вашему классу хранилища и рабочей нагрузке, а не копируйте универсальное число.
• Базовые показатели производительности: Знайте, как выглядит «нормальная» задержка ввода-вывода для вашей конкретной рабочей нагрузки. Это облегчает обнаружение аномалий.
• Понимание типа рабочей нагрузки: Случайные шаблоны ввода-вывода (обычные для баз данных) вызывают гораздо более высокую задержку, чем последовательный ввод-вывод (обычный для потоковой передачи мультимедиа или чтения больших файлов).

Лучшие расследования задержки диска постоянно сужают вопрос: какое устройство, какая файловая система, какой процесс, какая рабочая нагрузка и какое недавнее изменение? Как только у вас есть эта цепочка, исправление обычно становится яснее. Вы перестаёте случайно настраивать параметры ядра и начинаете изменять расписание резервного копирования, добавлять память, ремонтировать хранилище, исправлять запрос или перемещать шумную рабочую нагрузку с общего диска.