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