BLK-MQ и планировщики ввода-вывода

Системы хранения данных считаются классическим «узким местом» на серверах. Поэтому производители накопителей регулярно предлагают рынку новые технологии для увеличения скорости работы дисков, роста их объема и надежности. Но такой подход приводит к появлению других проблем. Например, к тому, что механизмы ядра Linux уже не могут справиться с обслуживанием скоростных накопителей.

Современные релизы Linux позволяют использовать специальный софт, который получил название «планировщики для блочных устройств». Их работа основана на новом способе передачи запросов – Multiqueue Block Layer (или BLK-MQ). Подобные системы работают и в ЦОД провайдера cloud.timeweb.com, чтобы давать доступ клиентам к имеющимся ресурсам без лимитов, иногда появляющихся из-за несовершенства программного обеспечения.

Общая информация

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

Причем образовавшаяся очередь так и остается «узким местом» для операционной системы, потому что время завершения всех поставленных в нее задач так или иначе остается неизменным. Поэтому ряд специалистов решает проблему отправкой запросов напрямую в драйверы устройств. Отчасти такой подход помогает, ведь он позволяет избежать общей очереди. Но при активной эксплуатации внутри драйверов образуются свои очереди (система характерна для виртуальных машин).

Решение появилось в 2013 году – это BLK-MQ, или Multiqueue Block Layer. Запросы сначала попадают в стандартную программную очередь, количество которых равно числу ядер серверного процессора. Последовательно они попадают в очередь отправки, их в зависимости от драйвера устройства может быть от 1 до 2048. Планировщик раскидывает запросы во все свободные потоки без жесткой привязки к конкретной очереди.

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

Вернемся к стандартным решениям. В большей части дистрибутивов Linux обычно интегрированы три планировщика – NOOP, CFQ и DEADLINE. Первый из них получил название от сокращения фразы «No Operation». Он выполняет создание простых FIFO-очередей без возможности изменять последовательность запросов внутри них. Плюс он объединяет запросы к соседним блокам. Все более сложные задачи остаются за нижележащим уровнем, например аппаратным RAID-контроллером.

CFQ (Completely Fair Queueing) работает чуть посложнее:

1. Пропускная способность системы делится между активными процессами.
2. Синхронные запросы объединяются в отдельные очереди на каждый процесс.
3. Запросы асинхронного типа система объединяет исходя из приоритетов.
4. Проводится сортировка запросов для снижения времени поиска секторов на диске.
5. Приоритет выполнения запросов между очередями настраивают утилитой ionce.

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

Принцип действия был выбран исходя из практики, согласно которой большинство приложений в случае временной нехватки ресурсов блокируются именно на чтении, а не на записи или других процессах. Хотя всех трех вариантов обслуживания оказалось недостаточно с появлением дисков NVMe. С их появлением пришлось разрабатывать новые решения для BLK-MQ: NONE, BFG, MQ-DEADLINE и KYBER.

Планировщики процессов BLK-MQ

При использовании технологии BLK-MQ есть смысл отключить стандартные планировщики путем переключения в режиме none. Относительно популярный инструмент BFG стал наследником CFQ в плане алгоритма и настроек. Здесь тоже идет группировка синхронных запросов по задачам, а асинхронных по устройствам. Новым является применения планировщика Round Robin, в который заложено понятие бюджетов, определяющих алгоритм распределения приоритетов.

Мало чего кардинально нового появилось и в MQ-Deadline. Это всего лишь адаптация предыдущей утилиты под особенности алгоритмов BLK-MQ. Работает такая система все с тем же приоритетом в пользу запросов на чтение данных с накопителей. Схожий принцип используется и в программе Kyber.

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

Инсталляция планировщика

В старых версиях ядра (до 4.12.0) процесс инсталляции планировщика был усложнен тем, что требовался патчинг для включения поддержки BFQ-v7r2. Однако в новых версиях, начиная с 4.12.0, такая необходимость отсутствует — BFQ уже включен в ядро Linux, и дополнительных действий не требуется. При этом в любом случае рекомендуется обновить ядро до последней версии.

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

$ sudo apt-get install hdparm bonnie++

Все, сервер готов к эксплуатации и предварительному тестированию дисковой подсистемы.

По умолчанию BFQ настроен достаточно эффективно, все-таки его и разрабатывали под задачи по увеличению производительности. Но при желании поэкспериментировать можно изменить часть параметров, который записаны в конфигурационном файле /sys/block/sda/queue/iosched.

Чаще тестируют с изменением настроек:

• slice_idle – по умолчанию 8 миллисекунд. Время ожидания поступления запросов.
• quantum – по умолчанию 4. Число запросов, передаваемых за один прием.
• low_latency – по умолчанию отдается приоритет интерактивным процессам.
• max_budget – по умолчанию 0. Максимальный бюджет в количестве секторов.

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

Тестирование

Проверить влияние планировщика на работу дисковой подсистемы весьма затруднительно. Простой однопоточный тест, скорее всего, покажет сходные результаты как до, так и после установки BLK-MQ. Но в реальной практике такие процессы редки, чаще происходит многопоточная загрузка, ее же получить можно только при использовании какого-то реального приложения. Или провести ряд синтетических тестов, имитирующих «бурную деятельность».

В качестве примера при тестировании разных вариантов системы будем замерять значение Latency, задержки при выполнении запросов при наибольшей скорости передачи данных, доступной тому или иному типу накопителей. В качестве платформы используем сервер 2 x Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.40GHz со 128 Гбайт ОЗУ и предустановленной Ubuntu 16.04 с версией ядра 4.13.0-17, взятой из официального репозитория.

Результаты двухчасового теста с жестким диском 8ТБ HGST HUH721008AL:

1. Скорость работы при использовании любого стандартного планировщика практически не отличается друг от друга.
2. Периодически возникали всплески с резким увеличением Latency, чего не наблюдалось при включенных планировщиках категории BLK-MQ.
3. Наихудшие результаты из последних показывает BFQ со значением до 6 секунд на запись и до 2,5 секунд на чтение.
4. Наименьший результат показал Kyber – это 128 мс на запись и 136 мс на чтение, чуть хуже у MQ-Deadline – 173 мс и 289 мс соответственно.

Выводы простые – с жесткими дисками переходить на новые планировщики особого смысла нет, хоть они и показывают улучшение работы дисковой подсистемы в целом. Здесь HDD остается тем самым «узким местом», которым он является из-за конструктивных особенностей накопителей. Это и определяет массовый переход минимум на SSD (твердотельные диски), которые мы и протестируем во вторую очередь.

В этом случае используем платформу Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz с 64 Гбайт ОЗУ и 1.6TB INTEL SSD DC S3520 Series. В качестве операционной системы используем Ubuntu 14.04 с ядром 4.12.0-041200-generic. Вкратце о результатах тестирования:

1. На твердотельном накопителе стандартные планировщики показали резко худшие значения задержки на чтение, особенно «отличился» CFQ.
2. Наилучшие показатели оказались у Kiber, эта утилита показала самую маленькую задержку при чтении, до 7 раз меньше даже в сравнении с Deadline.
3. Максимальные значения Latency для MQ-Deadline и BFQ при чтении с SSD составили 2,7 секунды, что заметно ниже, чем в случае с HDD.

Интересная ситуация возникла с CFQ: утилита по неизвестной причине отдавала приоритет любым запросам на запись, чем и ухудшила свой показатель чтения данных. Такой алгоритм не очень хорошо сказывается на общей эффективности, ведь считыванию принято отдавать максимальные «полномочия». В этом случае работа BFQ представляется более «честной», нацеленной именно на рост производительности, а не бездумно» перераспределение приоритетов.

Теперь о NVMe. Ряд специалистов считает, что с ними вообще не требуется использовать какие-либо планировщики, и лучше сделать акцент на модернизации всего сервера для получения высокой пропускной способности как контроллеров ввода-вывода, так и остальной системы. Но в некоторых случаях решение об установке BLK-MQ остается оправданным. Например, когда важно уменьшить время задержки даже при снижении количества операций ввода-вывода за единицу времени.

При тестировании накопителя NVMe на той же платформе, что и с SSD, минимальных показателей Latency при чтении данных также достигла утилита Kyber (всего 0,612 мс против 1,3-1,4 секунд для остальных планировщиков). Продукт BFQ выделился довольно сильной нагрузкой на процессор в четвертом результате тестов. Если считать слева направо и сверху вниз, это сильно заметно.

Выводы

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

В целом, применение инструментов вроде BFQ Scheduler оправдано, особенно при установке твердотельных накопителей. Хоть MQ-Deadline и Kyber тоже используются активно, здесь лучше отталкиваться от тестирования сервера в реальных задачах и выбирать наилучший вариант. При выборе рекомендуется отталкиваться от следующих моментов:

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

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