Настройка I/O Scheduler на Linux: подбор планировщика для NVMe, SSD, HDD

Планировщик ввода-вывода: где очередь задач тормозит диски

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

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

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

Дальше — как найти это место в метриках и как оно закрывается.

Что меняется в работе дисков после подбора режима

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

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

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

Третий, самый заметный для бизнес-логики результат — стабильность отклика приложений. Уходит класс отказов «диск занят, приложение ждёт»: запрос не зависает на пике, потому что очередь под него спроектирована. Хвостовые задержки выравниваются, разброс между быстрыми и медленными операциями сокращается, и сервис держит ровное время ответа под нагрузкой, а не только в простое.

Выбор планировщика под NVMe, SSD и HDD

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

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

Отдельно проверяем режим переупорядочивания запросов: на HDD и SATA SSD склейка соседних блоков сокращает число операций, а на NVMe она дублирует работу контроллера и добавляет накладные расходы. Итоговый вариант выбираем по замерам на реальном профиле нагрузки — синтетика на пустом диске почти всегда врёт.

Порядок внедрения: от аудита нагрузки до передачи регламента

Планировщик ввода-вывода нельзя выставить «по умолчанию»: узел под базой, сервис с логами и хранилище образов дают разный профиль обращений к диску. Порядок работ идёт от измерений к решению — сначала аудит, потом режим, затем закрепление в конфигурации.

1. Аудит нагрузки на диск. Снимаем глубину очереди, соотношение чтения и записи, размер запроса и время отклика по каждому устройству — это база, с которой сравниваем всё дальнейшее.
2. Схема очередей. Размечаем диски по назначению и считаем, сколько очередей приходится на устройство и где узкое место: сам накопитель или очередь к нему.
3. Подбор режима. На NVMe переупорядочивание запросов почти не даёт выигрыша, на SSD с параллельными очередями работает многопоточный режим, на HDD — с накоплением и сортировкой запросов.
4. Стенд для проверки режима. Разворачиваем копию контура, повторяем профиль из аудита и сравниваем задержку и пропускную способность с базой. Режим без выигрыша на стенде на боевой узел не едет.
5. Переключение по узлам. Меняем поэтапно, с откатом за один шаг, и сразу закрепляем правило в конфигурации — иначе после перезагрузки или обновления ядра значение вернётся к прежнему.
6. Проверка на реальном трафике. Смотрим поведение на пике и в часы низкой нагрузки: время отклика, длину очереди, регрессию на соседних сервисах.
7. Передача регламента обслуживания. Отдаём документ: какой режим какому классу дисков положен, как проверить текущее значение, как откатиться и какие метрики смотреть.

Комплект документации и настроек на выходе

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

• Файлы конфигураций планировщика ввода-вывода и правил устройств — под контролем версий, с комментарием к каждому исключению: почему для этого тома выбран не общий профиль.
• Схема очередей и приоритетов: какие очереди обслуживают базы, журналы, резервное копирование, какой у них вес и глубина, что происходит при переполнении.
• Карта распределения задач по накопителям: том, тип носителя, назначенный планировщик и результат замеров, на которых выбор основан.
• Регламент обслуживания серверов: что перепроверять после обновления ядра или замены диска, в какой момент профиль перестаёт быть актуальным.
• Инструкция для дежурной смены: как переключить планировщик на работающей системе, как вернуть предыдущее значение и по каким метрикам понять, что стало хуже.
• Методика замеров: сценарии нагрузки, число повторов, набор снимаемых показателей задержки и пропускной способности — чтобы спорные решения решались цифрами.
• Инвентаризация узлов с отклонениями от эталона и план приведения их к общему состоянию.

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

Разбор: высоконагруженная база перестала упираться в диск

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

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

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

Метрики до и после: время ожидания дисковых операций на 99-м процентиле сократилось в 6–8 раз, доля ожидания ввода-вывода упала с четверти до 2–3%. Периодические провалы по отклику прекратились — вместо всплесков раз в несколько минут график стал ровным, а окно бэкапа сократилось настолько, что перестало пересекаться с пиковой нагрузкой. Узел перестал упираться в диск, и запас по нагрузке остался на том же железе.

Что делать, если на узле смешаны база и файловые задачи?

Один планировщик ввода-вывода на смешанном узле всегда проигрывает: он настроен под один профиль. Включите bfq ради честности файловых операций — транзакции начнут платить накладными на каждой операции; поставите простой планировщик ради минимальной задержки — фоновые задачи займут очередь целиком. Поэтому смешанную нагрузку на узле разводят по устройствам, а не ищут одно универсальное правило.

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

Приоритеты операций ввода-вывода задают независимо от приоритета процесса: классы реального времени, best-effort и idle, а также веса и лимиты операций в секунду в cgroup. Фоновые задания держим в idle — такой класс получает полосу только при свободном устройстве и вытеснить транзакции не может. Всплеск от бэкапа снимают лимитом операций, а не повышением приоритета.

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

Технические сомнения перед сменой режима обработки очереди

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

Есть риск потерять данные?

Планировщик не пишет на носитель — он решает, в каком порядке ядро отдаёт запросы. Формат, метаданные и содержимое томов не затрагиваются, поэтому потери данных от самой смены режима нет. Риск в другом: правка под пиковой нагрузкой без наблюдения за задержкой и глубиной очереди. Поэтому сначала снимаем исходные метрики, потом меняем.

Что делать при замене накопителей?

Новый диск приходит с режимом по умолчанию — отсюда «после замены стало медленнее». Правило привязываем к типу носителя, а не к имени устройства: NVMe, SATA SSD и HDD получают свои режимы автоматически. Замена диска или добавление узла тогда не требует ручной настройки.

Как откатиться, если стало хуже?

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

Обсудим задачу и вернёмся с оценкой и планом

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

Для старта пришлите:

• состав узлов и типы носителей — NVMe, SATA SSD, HDD и их роль в системе;
• профиль нагрузки: база данных, очереди сообщений, файловое хранилище, виртуализация;
• текущий сценарий — какой планировщик выбран и как заданы параметры очереди;
• симптом с цифрами: просадки записи, рост времени отклика, неравномерная загрузка ядер;
• ограничения — окно обслуживания, требования к откату и внутренние регламенты;
• стенд или сервер, где можно воспроизвести поведение до правок в рабочем контуре.

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

По итогу приходит оценка и план работ: этапы, целевые параметры очереди по каждому классу носителей, порядок выката с точкой отката и перечень проверок, по которым видно результат. Настройка серверов Linux ведётся так, чтобы изменения жили в конфигурации и переносились на новые узлы одной командой, а не оставались правкой на одном сервере.

Опишите задачу — вернёмся с оценкой и планом.