Тонкая настройка планировщика ввода-вывода

MAATRIX

Диск в сервере не обрабатывает запросы в том порядке, в котором их отправило приложение — между файловой системой и физическим накопителем стоит планировщик ввода-вывода (I/O scheduler), который решает, что отправить первым, а что можно объединить. Для механического HDD правильный выбор экономит реальные миллисекунды на каждой операции, а для SSD и NVMe та же логика иногда просто тратит CPU впустую. Разберёмся, как это устроено и что стоит поменять на вашем сервере.

Что делает планировщик ввода-вывода

Когда процесс читает или пишет данные, запрос не летит на диск мгновенно. Он попадает в очередь блочного слоя ядра (block layer), и уже оттуда планировщик решает:

• в каком порядке отдать накопившиеся запросы устройству;
• какие соседние по адресам запросы объединить (merge) в один, чтобы сократить число операций;
• как балансировать между чтением и записью, чтобы ни один тип запросов не голодал бесконечно.

Современные ядра Linux (начиная примерно с 4.x, окончательно — после отказа от старого однопоточного блочного слоя в пользу multi-queue block layer, blk-mq) работают именно через blk-mq. У каждого устройства свой набор доступных планировщиков, и увидеть их можно прямо из /sys:

cat /sys/block/sda/queue/scheduler
[mq-deadline] kyber bfq none

Планировщик в квадратных скобках — активный, остальные — просто доступны для переключения.

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

Почему для HDD переупорядочивание — это реальная экономия

У механического жёсткого диска есть головка чтения-записи, которая физически перемещается над вращающимися пластинами. Чтобы прочитать данные с другой дорожки, головке нужно физически туда переместиться (seek time) и дождаться, пока нужный сектор подъедет под неё (rotational latency). Это не абстракция — это миллисекунды, и на фоне скорости самой передачи данных они огромны.

Отсюда классическая идея планировщиков эпохи HDD (в старых ядрах — CFQ, deadline; сейчас их наследник — mq-deadline): сортировать и группировать запросы по номерам секторов (LBA), а не по времени поступления. Это называют elevator-алгоритмом по аналогии с лифтом — он не бегает туда-сюда за каждым пассажиром, а едет в одну сторону, забирая всех попутных.

Что конкретно это даёт на HDD:

• запросы к близко расположенным на диске данным обрабатываются вместе — головка делает один проход вместо нескольких;
• при интенсивной нагрузке снижается суммарное время seek;
• deadline-компонент следит, чтобы старые запросы (особенно чтение) не откладывались бесконечно ради оптимальной сортировки — у каждого запроса есть предельный срок.

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

Почему на SSD и NVMe та же логика теряет смысл

У флеш-памяти нет головки и нет механического перемещения. Произвольный доступ к любому адресу стоит примерно одинаково — что соседний блок читать, что противоположный конец накопителя. Контроллер SSD и так параллельно работает с десятками флеш-чипов, и у него собственная логика распределения запросов (wear leveling, внутреннее переупорядочивание на уровне FTL — flash translation layer), которая уже учитывает реальную физику устройства лучше, чем планировщик ядра.

Из этого следует не слишком очевидный, но важный вывод: сортировка запросов ради минимизации несуществующего механического перемещения — это работа, которая ничего не даёт устройству, но стоит CPU-времени планировщику. В лучшем случае — нейтрально. В худшем — на очень быстрых NVMe с задержками в единицы-десятки микросекунд, лишняя обработка в планировщике (взять блокировку очереди, отсортировать, смержить) может занять сопоставимое или большее время, чем сама операция на устройстве заняла бы без всякой сортировки.

NVMe усугубляет ситуацию архитектурно: протокол изначально спроектирован для параллелизма — до 65535 очередей команд по 65535 команд в каждой, с прямым доступом без единой точки конкуренции. Многоуровневая программная сортировка запросов поверх этого — это борьба с проблемой, которой на таком устройстве уже почти не существует.

Практическая рекомендация: none/noop против mq-deadline

Отсюда рабочее правило, которое стоит проверять, а не принимать слепо:

none (в старых ядрах — noop) — это минимальный планировщик: он делает базовое слияние соседних запросов и отдаёт их устройству практически в порядке поступления, без сложной сортировки по LBA и без дедлайнов. Это не «отсутствие планировщика» в буквальном смысле, а самый дешёвый по CPU вариант — прямая передача с минимумом накладных расходов.

Стоит отметить честно: многие современные дистрибутивы уже сами выбирают разумный планировщик по умолчанию — ядро смотрит на глубину аппаратной очереди устройства и часто ставит none для NVMe и mq-deadline для однопоточных SATA-устройств автоматически, ещё на этапе загрузки. Поэтому первый шаг — не менять, а проверить, что реально стоит сейчас.

Как проверить текущий планировщик

Определите тип накопителя — вращающийся он или нет:

cat /sys/block/sda/queue/rotational

1 — механический HDD, 0 — SSD или NVMe.

Посмотрите доступные и активный планировщик для конкретного устройства:

cat /sys/block/sda/queue/scheduler
cat /sys/block/nvme0n1/queue/scheduler

Вывод вида [mq-deadline] kyber none означает, что активен mq-deadline, а kyber и none доступны для переключения. На части систем bfq тоже присутствует в списке — это планировщик с упором на честность между процессами (полезен на десктопах и multi-tenant нагрузках, но дороже по CPU, чем none).

Как сменить планировщик — временно и навсегда

Временная смена (до перезагрузки) — просто запишите имя нужного планировщика в тот же файл:

echo none | sudo tee /sys/block/nvme0n1/queue/scheduler
echo mq-deadline | sudo tee /sys/block/sda/queue/scheduler

Это изменение живёт только до перезагрузки — при рестарте вернётся значение по умолчанию, выбранное ядром или дистрибутивом. Для постоянной настройки есть два пути.

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

# /etc/udev/rules.d/60-io-scheduler.rules
ACTION=="add|change", KERNEL=="sd[a-z]|nvme[0-9]n[0-9]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"
ACTION=="add|change", KERNEL=="sd[a-z]|nvme[0-9]n[0-9]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="mq-deadline"

После создания файла примените правило без перезагрузки:

sudo udevadm control --reload-rules
sudo udevadm trigger

Через параметр загрузки ядра (более грубый способ — задаёт планировщик глобально, без учёта разных типов устройств в одной системе). В /etc/default/grub добавьте в GRUB_CMDLINE_LINUX:

elevator=none

и обновите загрузчик (sudo update-grub на Debian/Ubuntu или sudo grub2-mkconfig -o /boot/grub2/grub.cfg на RHEL-подобных). Стоит знать, что параметр elevator= в современных ядрах частично устарел и на некоторых версиях игнорируется в пользу udev-правил — поэтому если у вас смешанная инфраструктура с HDD и SSD на одном хосте, udev-правило по флагу rotational — надёжнее и гибче.

Частые вопросы