Настройка планировщика ввода-вывода Linux: mq-deadline, none и BFQ

Планировщик ввода-вывода Linux определяет порядок, в котором запросы на чтение и запись поступают на ваше устройство хранения, и правильный выбор зависит почти полностью от вашего оборудования. Используйте none для NVMe, mq-deadline для SATA SSD и HDD, работающих со смешанными рабочими нагрузками, и bfq когда вам нужно предотвратить ситуацию, при которой один процесс «забирает» ресурсы у других. В этом руководстве рассказывается, как работают три основных планировщика, как подобрать подходящий для вашей рабочей нагрузки, а также как настроить его и проверить результат.

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

Чем отличаются mq-deadline, none и BFQ

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

mq-deadline

Планировщик mq-deadline планировщик гарантирует, что ни один запрос не будет ждать бесконечно. Он поддерживает отдельные отсортированные очереди для чтения и записи, упорядочивая их по логическому адресу блока (LBA) для сокращения времени поиска, и обеспечивает соблюдение сроков: по умолчанию 500 мс для чтения и 5 секунд для записи. Когда запрос достигает своего срока, он перемещается в начало очереди.

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

нет

Планировщик none планировщик практически ничего не делает. Он передает запросы прямо на устройство в порядке «первым пришел — первым обслужен» (First-In-First-Out), без переупорядочивания, объединения или приоритезации. Это подходит для современных дисков NVMe, которые управляют своими собственными внутренними очередями и могут отслеживать десятки тысяч запросов одновременно. Удаление программного уровня планирования обеспечивает кратчайший путь от приложения к устройству, что именно и требуется для высокопроизводительных рабочих нагрузок NVMe.

Загвоздка в том, что это работает только тогда, когда аппаратное обеспечение само по себе может разумно планировать работу. На жестких дисках или SSD-накопителях SATA с небольшими очередями пропуск программной переупорядочки обычно ухудшает производительность, а не улучшает ее.

BFQ

BFQ (Budget Fair Queuing) ставит справедливость на первое место. Вместо временных интервалов он выделяет каждому процессу бюджет, измеряемый в секторах диска. Крупные последовательные читающие процессы получают большие бюджеты для поддержания пропускной способности, в то время как задачи, чувствительные к задержкам, получают меньшие бюджеты, чтобы их обслуживание происходило быстро, а цикл обратной связи корректирует бюджеты по ходу работы.

BFQ обеспечивает отзывчивость интерактивных задач даже при высокой нагрузке, так что воспроизведение видео или запрос к базе данных остаются плавными, пока в фоновом режиме выполняется передача большого файла. Эта справедливость обходится в за счет ресурсов ЦП. Накладные расходы на каждый запрос составляют примерно 1,9 микросекунды, что примерно в три раза больше, чем у mq-deadline, и на более медленном ядре ARM эти накладные расходы ограничивают пропускную способность значительно ниже того, чего достигает тот же планировщик на быстром чипе x86. На серверах, где сырая пропускная способность и эффективность ЦП имеют наибольшее значение, этот компромисс трудно оправдать.

Подбор планировщика под вашу рабочую нагрузку

Выбор подходящего планировщика зависит от двух факторов: вашего аппаратного обеспечения хранения данных и схемы доступа вашего приложения. Начнем с аппаратного обеспечения. Если устройство уже переупорядочивает запросы, например, диск NVMe с соответствующей прошивкой, программное планирование только увеличивает нагрузку, поэтому none выигрывает. На вращающихся жестких дисках, где доминирует время поиска, программная переупорядочка сокращает задержку, поэтому mq-deadline или bfq являются лучшим выбором. SSD-накопители SATA занимают промежуточное положение: они быстрее жестких дисков, но не имеют глубоких очередей NVMe, и именно здесь mq-deadline подходит.

Та же логика применима, когда планированием уже занимается что-то другое. Гостевые виртуальные машины на virtio-blk полагаются на хост при планировании ввода-вывода, а аппаратные RAID-контроллеры с кэшем с отложенной записью оптимизируют свою собственную упорядочку. В обоих случаях none избегается двойная оплата работы.

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

Стоит отметить одно исключение. Даже на NVMe, если вас интересует показатель конечной задержки на p99 или p999, например, в финансовых системах, mq-deadline может превзойти none за счет соблюдения строгих сроков и предотвращения случайных задержек запросов.

Изменение и настройка параметров планировщика

Как переключение планировщиков, так и настройка их параметров осуществляется через sysfs, при этом для проверки изменений не требуется перезагрузка.

Переключение активного планировщика

Проверьте, что доступно для устройства, где значение в скобках является активным:

cat /sys/block/sda/queue/scheduler

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

echo bfq | sudo tee /sys/block/sda/queue/scheduler

Если bfq не указан в списке, сначала загрузите модуль:

sudo modprobe bfq

Чтобы выбор сохранился, используйте правило udev вместо старого elevator= параметр ядра, который больше не изменяет планировщик в RHEL 9 и подобных выпусках. Это правило устанавливает mq-deadline для всех неротационных дисков SCSI в /etc/udev/rules.d/60-io-scheduler.rules:

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"

Перезагрузите и примените его без перезагрузки:

sudo udevadm control --reload-rules && sudo udevadm trigger

В системах на базе RHEL профили TuneD выполняют ту же задачу с помощью общесистемных профилей вместо правил для отдельных устройств.

Параметры, которые стоит настраивать

Каждый планировщик предоставляет доступ к своим настройкам в /sys/block/<device>/queue/iosched/. Для mq-deadline, основными рычагами являются сроки выполнения. Базы данных, чувствительные к задержкам, на SATA SSD выигрывают от более коротких сроков:

echo 100 | sudo tee /sys/block/sda/queue/iosched/read_expire
echo 1000 | sudo tee /sys/block/sda/queue/iosched/write_expire

Для bfq систем с высокой пропускной способностью отключение эвристики задержки повышает пропускную способность:

echo 0 | sudo tee /sys/block/sda/queue/iosched/low_latency
echo 0 | sudo tee /sys/block/sda/queue/iosched/slice_idle

Для виртуального хостинга BFQ хорошо сочетается с cgroups v2. Назначение io.weight значений позволяет, например, предоставить процессу базы данных в десять раз большую долю ввода-вывода, чем заданию резервного копирования, чтобы фоновая работа не заглушала интерактивный трафик. Что бы вы ни изменили, более высокая стоимость обработки одного запроса в BFQ суммируется на системах с ограничением по ЦП и высоким показателем IOPS, поэтому перед внедрением проведите тестирование.

Проверка производительности после настройки

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

fio — стандартный инструмент для этого. Он воспроизводит определенные шаблоны нагрузки с помощью настроек размера блока, глубины очереди и механизма ввода-вывода. Всегда запускайте --direct=1 , чтобы обойти кэш страниц и измерить работу планировщика и устройства напрямую, а не кэшированные чтения. Сопоставьте тест с реальной нагрузкой:

Запустите тот же тест с iodepth значениям от 1 до 256, чтобы найти точку насыщения устройства — глубину, на которой IOPS перестают расти, а задержка резко возрастает. Для мониторинга в режиме реального времени после изменения iostat -x 1 сообщает важные показатели: r_await и w_await задержку завершения чтения и записи, aqu-sz для средней глубины очереди и %util для загрузки устройства. Когда %util находится вблизи 100 процентов, ограничением является аппаратное обеспечение, и никакие изменения в планировщике не помогут.

Чтобы отделить затраты на программное обеспечение от затрат на аппаратное обеспечение, запустите blktrace с btt. Он разбивает задержку на Q2D — время, проведенное в программной очереди, — и D2C — время, которое требуется устройству для обработки запроса. Если преобладает Q2D, то узким местом является планировщик. Если преобладает D2C, то — аппаратное обеспечение.

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

Выбор подходящего планировщика

Настройка планировщика заключается в адаптации алгоритма к аппаратному обеспечению и модели доступа, а затем в проверке результатов с помощью измерений. Краткая версия:

• NVMe: используйте none и позвольте прошивке заниматься управлением очередями.
• SSD и HDD с интерфейсом SATA со смешанными операциями ввода-вывода: используйте mq-deadline для предсказуемой задержки.
• Общие или многопользовательские хосты: используйте bfq , чтобы одна рабочая нагрузка не лишала ресурсов остальные.
• Следите за латентностью в хвосте распределения, а не за медианой: изменения в работе планировщика проявляются на p99 и p999, поэтому именно их и нужно измерять.
• Обеспечьте постоянство: используйте правила udev или TuneD, но ни в коем случае не параметр dead elevator= параметр.

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