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) работает чуть посложнее:
- Пропускная способность системы делится между активными процессами.
- Синхронные запросы объединяются в отдельные очереди на каждый процесс.
- Запросы асинхронного типа система объединяет исходя из приоритетов.
- Проводится сортировка запросов для снижения времени поиска секторов на диске.
- Приоритет выполнения запросов между очередями настраивают утилитой 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:
- Скорость работы при использовании любого стандартного планировщика практически не отличается друг от друга.
- Периодически возникали всплески с резким увеличением Latency, чего не наблюдалось при включенных планировщиках категории BLK-MQ.
- Наихудшие результаты из последних показывает BFQ со значением до 6 секунд на запись и до 2,5 секунд на чтение.
- Наименьший результат показал 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. Вкратце о результатах тестирования:
- На твердотельном накопителе стандартные планировщики показали резко худшие значения задержки на чтение, особенно «отличился» CFQ.
- Наилучшие показатели оказались у Kiber, эта утилита показала самую маленькую задержку при чтении, до 7 раз меньше даже в сравнении с Deadline.
- Максимальные значения 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 тоже используются активно, здесь лучше отталкиваться от тестирования сервера в реальных задачах и выбирать наилучший вариант. При выборе рекомендуется отталкиваться от следующих моментов:
- Возможности аппаратных контроллеров, способных работать без участия процессора.
- Результаты тестирования при пиковых нагрузках, на которые вообще рассчитан сервер.
- Показатели при запросе последовательной записи-чтения и при случайном выборе данных.
Стоит учитывать и тот факт, что все перечисленные планировщики продолжают развиваться. И в новых релизах алгоритм вполне может измениться настолько кардинально, что придется подбирать новый инструмент для увеличения производительности дисковой подсистемы.