Что такое фронтальное слияние в планировании ввода / вывода и как я могу настроить этот параметр?
В моем Linux используется алгоритм Deadline для планирования ввода / вывода. Одним из параметров является front_merges параметр под /sys/block/sda/queue/iosched/front_merges, По умолчанию установлено значение 1, что означает, что вероятнее всего произойдет слияние фронтов. Можно установить значение 0, чтобы повысить производительность, если вы не ожидаете, что произойдет слияние фронтов.
- Какие именно фронтальные слияния? Может кто-нибудь изобразить это, пожалуйста?
- Как мне узнать или проверить, происходят ли слияния в моей системе или нет?
2 ответа
Документация ядра говорит это лучше всего:
Иногда случается, что запрос поступает в планировщик ввода-вывода, смежный с запросом, который уже находится в очереди. Либо он помещается в конце этого запроса, либо он помещается спереди. Это называется кандидатом на обратное слияние или кандидатом на фронтальное слияние. Из-за того, как файлы обычно располагаются, обратные слияния встречаются гораздо чаще, чем фронтальные слияния. Для некоторых рабочих нагрузок вы можете даже знать, что тратить время на попытки обработки запросов на слияние - пустая трата времени. Установка front_merges в 0 отключает эту функцию. Фронтальное слияние все еще может происходить из-за кэшированной подсказки last_merge, но так как это происходит в основном по цене 0, мы оставляем это включенным Мы просто отключаем поиск переднего сектора rbtree при вызове функции слияния планировщика io.
Причина, по которой передние слияния встречаются редко, заключается в том, что записывающие устройства обычно не записывают блоки на диск в обратном порядке.
Рассмотрим процесс, который выполняет простую последовательную запись нового файла, содержащего два блока. Сначала он записывает блок 0, затем записывает блок 1. Когда блок 1 попадает в очередь, он находится позади блока 0, поэтому ядро выполняет обратное слияние, а затем отправляет оба блока на физический диск одновременно. Это типичный случай.
Чтобы получить фронтальное слияние, процесс должен сначала записать блок 1, затем выполнить поиск назад и записать блок 0. Это не типичный случай, хотя для некоторых рабочих нагрузок это происходит (например, базы данных).
Я бы не ожидал, что изменение производительности будет таким значительным, даже при высоких показателях ввода-вывода. Вы можете проверить это обоими способами на своей фактической рабочей нагрузке. Если вы не занимаетесь чем-то интенсивным, то это не так важно.
Красная Шляпа говорит:
front_merges: Вы можете установить эту переменную на 0, если знаете, что ваша рабочая нагрузка никогда не будет генерировать фронтальные слияния. Если вы не измерили накладные расходы на эту проверку, рекомендуется оставить ее по умолчанию (1).
Поэтому рекомендуется оставить значение по умолчанию. Я могу сказать вам, что я обычно не изменяю этот параметр в своих усилиях по настройке, но это зависит от вашей рабочей нагрузки.
Смотрите: Linux - реальная настройка аппаратного RAID-контроллера (scsi и cciss)
Также наилучшим подходом является научный подход к тестированию ваших данных, систем и среды.
Вы можете отслеживать активность слияния, используя iostat -x командование и отслеживание rrqm/s а также wrqm/s поля в выводе. Все, что не является НУЛЕМ в этих столбцах, указывает на то, что непрерывные запросы были объединены до их доставки в основное хранилище. Это также указывает на то, что рабочая нагрузка является последовательной.
Если вы не видите активности в этих столбцах, изменение настраиваемого срока front_merge не принесет вам пользы.
Вы не предоставили каких-либо реальных деталей в своем вопросе о типе сервера или подсистеме хранения. Если вы используете какой-либо аппаратный RAID с кэшированием или определенные файловые системы, они влияют на влияние этого настраиваемого параметра.