Команда cat /sys/block/sda/queue/scheduler выводит строку вида mq-deadline [bfq] none, где значение в квадратных скобках — активный планировщик ввода-вывода вашего диска. Именно этот параметр определяет, в каком порядке ядро Linux отправляет запросы чтения и записи на накопитель, и его неудачный выбор заметно снижает отзывчивость системы при фоновой нагрузке на диск.
В этой статье разберём, что делает планировщик I/O, какие варианты доступны в современных ядрах Linux, как проверить текущий режим и переключить его под HDD, SATA SSD или NVMe. Отдельно рассмотрим типичные симптомы неверного выбора и способы закрепить настройку после перезагрузки.
Что такое планировщик I/O и зачем он нужен
Планировщик ввода-вывода (I/O scheduler) — это подсистема ядра Linux, которая управляет очередью запросов к блочному устройству. Когда несколько процессов одновременно обращаются к диску, ядро не передаёт запросы напрямую, а накапливает их, сортирует и объединяет, чтобы сократить лишние операции и снизить задержки.
Для классического жёсткого диска с вращающимися пластинами порядок обращений критичен: каждое перемещение головки занимает время, поэтому планировщик старается выстроить запросы по «лестнице» секторов. Для твердотельных накопителей механических задержек нет, но остаются проблемы справедливого распределения пропускной способности между процессами и приоритета чтения над записью.
Современные ядра используют инфраструктуру blk-mq (multi-queue block layer), из-за чего старые планировщики вроде CFQ и deadline были удалены из дерева исходников. Сейчас актуальный набор невелик, и выбор сводится к нескольким вариантам.
Доступные планировщики в современных ядрах
Точный список зависит от версии ядра и параметров сборки дистрибутива, поэтому всегда сверяйтесь с выводом /sys/block/имя_диска/queue/scheduler на вашей системе. В большинстве актуальных дистрибутивов встречаются следующие варианты:
- ⚙️ mq-deadline — адаптация классического deadline для очередей blk-mq; гарантирует предельное время ожидания запроса, приоритет отдаёт чтению. Часто выбирается по умолчанию для SATA SSD и HDD.
- ⚖️ BFQ (Budget Fair Queueing) — ориентирован на справедливое распределение полосы между процессами и отзывчивость рабочего стола; полезен, когда фоновое копирование не должно «подвешивать» интерфейс.
- 🚀 Kyber — лёгкий планировщик, нацеленный на низкую задержку быстрых устройств, прежде всего NVMe; настраивается токенами глубины очереди.
- 🚫 none — отсутствие планирования: запросы уходят в аппаратную очередь напрямую. Типичный выбор для NVMe, где свой контроллер очередей в самом устройстве.
Важно понимать: на очень быстрых накопителях накладные расходы сложного планировщика могут превышать выигрыш от переупорядочивания запросов. Именно поэтому для NVMe многие дистрибутивы выбирают none или kyber, а для медленных устройств — более «умные» алгоритмы.
Как проверить текущий планировщик
Проверка занимает одну команду и не требует прав root. Сначала определите имя блочного устройства через lsblk, затем прочитайте параметр из sysfs:
lsblk
cat /sys/block/sda/queue/scheduler
Вывод покажет все доступные для данного устройства планировщики, а активный будет выделен квадратными скобками, например: [mq-deadline] kyber bfq none. Обратите внимание, что набор может отличаться между дисками одной системы: для NVMe-устройства nvme0n1 и для SATA-диска sda списки нередко различаются.
⚠️ Внимание: если вместо ожидаемого списка вы видите только none, возможные причины — ядро собрано без дополнительных планировщиков или устройство обслуживается через драйвер, не поддерживающий их. Это не ошибка, а особенность конфигурации.
Как сменить планировщик I/O
Переключение выполняется записью имени планировщика в тот же файл sysfs. Операция применяется мгновенно и не требует размонтирования файловой системы, но сбрасывается после перезагрузки:
echo bfq | sudo tee /sys/block/sda/queue/schedulerПосле записи повторите чтение файла и убедитесь, что скобки переместились на новое значение. Если ядро отклонило запись, в выводе dmesg обычно появляется пояснение — например, что планировщик недоступен для данного типа устройства.
☑️ Смена планировщика I/O
Для постоянного применения настройки используются правила udev или параметры systemd — конкретный механизм зависит от дистрибутива. Универсальный подход через udev выглядит как правило, срабатывающее на добавление блочного устройства и записывающее нужное значение в атрибут queue/scheduler. Синтаксис правил стоит сверить с документацией вашей версии udev, так как детали могут отличаться.
Пример правила udev
Создайте файл /etc/udev/rules.d/60-scheduler.rules со строкой вида: ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="bfq". После сохранения выполните udevadm control --reload-rules и udevadm trigger. Проверьте результат после перезагрузки.
Какой планировщик выбрать под разные задачи
Однозначного «лучшего» варианта нет — выбор зависит от типа накопителя и характера нагрузки. Ориентируйтесь на общие рекомендации и обязательно проверяйте результат на своей системе, потому что поведение зависит от версии ядра, контроллера и паттерна обращений.
| Тип устройства / сценарий | Рекомендуемый вариант | Причина |
|---|---|---|
| Десктоп на HDD | bfq | Справедливое распределение, отзывчивый интерфейс при фоновой записи |
| Десктоп на SATA SSD | bfq или mq-deadline | Баланс задержки и пропускной способности |
| Сервер с БД на SSD | mq-deadline | Предсказуемые дедлайны запросов, приоритет чтения |
| NVMe-накопитель | none или kyber | Аппаратные очереди устройства, минимум накладных расходов |
| Виртуальная машина | none | Планирование уже выполняет гипервизор на хосте |
Виртуальные машины — особый случай: двойное планирование (в госте и на хосте) почти всегда вредно, поэтому внутри гостя разумно выставить none. Это одна из немногих ситуаций, где рекомендация достаточно устойчива между разными окружениями.
Признаки неподходящего планировщика
Проблема редко выглядит как явная ошибка — чаще это деградация отзывчивости, которую трудно привязать к конкретной причине. Обратите внимание на следующие симптомы:
- 🐌 Интерфейс «замерзает» на секунды во время копирования больших файлов или обновления системы.
- ⏱️ Приложения долго запускаются при фоновой индексации или работе антивирусного сканера.
- 📉 Низкая скорость последовательной записи на NVMe при включённом «тяжёлом» планировщике.
- 🔁 Резкие скачки задержки диска в мониторинге при смешанной нагрузке чтения и записи.
Диагностика начинается с наблюдения: утилиты iostat (пакет sysstat) и iotop показывают загрузку диска и процессы-виновники. Если при высоком await смена планировщика заметно меняет картину — настройка работает в правильном направлении.
⚠️ Внимание: не меняйте планировщик одновременно с другими параметрами (глубина очереди, readahead, файловая система). Иначе вы не сможете понять, какое изменение дало эффект. Меняйте по одному параметру и фиксируйте результат.
Тонкая настройка параметров планировщиков
У некоторых планировщиков есть настраиваемые параметры, доступные через каталоги вида /sys/block/sda/queue/iosched/. Например, у mq-deadline можно регулировать таймауты чтения и записи, у BFQ — поведение для устройств с низкой задержкой. Состав параметров зависит от версии ядра, поэтому ориентируйтесь на содержимое каталога и документацию ядра (Documentation/block/ в дереве исходников).
Менять эти значения стоит только при наличии измеримой проблемы: произвольная «оптимизация» без бенчмарка чаще ухудшает результат, чем улучшает. Значения по умолчанию подобраны разработчиками ядра под широкий спектр нагрузок.
⚠️ Внимание: настройки из каталога iosched, как и выбор планировщика, сбрасываются при перезагрузке. Если вы нашли удачную комбинацию, закрепите её через правило udev или стартовый скрипт, иначе система вернётся к исходному состоянию.
Часто задаваемые вопросы
Влияет ли планировщик I/O на скорость SSD?
На пиковую скорость — слабо, поскольку её определяет сам накопитель и интерфейс. Основное влияние планировщика — на задержку отдельных запросов и поведение системы под смешанной нагрузкой, когда несколько процессов конкурируют за диск.
Почему для NVMe рекомендуют none?
NVMe-устройства имеют собственные аппаратные очереди и очень низкие задержки. Программное переупорядочивание запросов в этом случае добавляет накладные расходы без заметной выгоды, поэтому прямой путь запросов часто эффективнее.
Нужно ли перезагружаться после смены планировщика?
Нет, запись нового значения в /sys/block/имя/queue/scheduler применяется немедленно. Перезагрузка требуется только для проверки того, что постоянное правило (udev или стартовый скрипт) срабатывает корректно.
Что делать, если нужного планировщика нет в списке?
Возможные причины: ядро собрано без его поддержки или устройство обслуживается драйвером, которому планировщик недоступен. Проверьте конфигурацию ядра и документацию дистрибутива; в некоторых случаях помогает установка альтернативного пакета ядра.
Может ли неправильный планировщик повредить данные?
Нет. Планировщик меняет только порядок и тайминг отправки запросов, целостность данных обеспечивается нижележащими слоями. Риск ограничивается производительностью и отзывчивостью системы.