Налаштування планувальника вводу-виводу 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 з високою пропускною здатністю.

Проблема полягає в тому, що це працює лише тоді, коли апаратне забезпечення може самостійно інтелектуально планувати. На HDD або SATA SSD з неглибокими чергами пропуск програмного переупорядкування зазвичай погіршує продуктивність, а не покращує її.

BFQ

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

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

Підбір планувальника відповідно до вашого навантаження

Дві речі визначають правильний планувальник: ваше апаратне забезпечення для зберігання даних та модель доступу вашої програми. Почніть з апаратного забезпечення. Якщо пристрій уже переупорядковує запити, як-от диск NVMe з відповідним вбудованим програмним забезпеченням, програмне планування лише додає навантаження, тому none перемагає. На обертових HDD, де домінує час пошуку, програмне переупорядкування скорочує затримку, тому mq-deadline або bfq є кращим вибором. SSD-накопичувачі SATA займають проміжне положення: вони швидші за HDD, але не мають глибоких черг 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-накопичувачі SATA та HDD зі змішаним вводом-виводом: використовуйте mq-deadline для передбачуваної затримки.
• Спільні або багатокористувацькі хости: використовуйте bfq , щоб одне навантаження не забирало ресурси у решти.
• Затримка хвоста, а не медіана: зміни планувальника відображаються на p99 та p999, тому саме це і слід вимірювати.
• Зробіть це постійним: використовуйте правила udev або TuneD, ніколи не використовуйте параметр elevator= параметр.

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