Вибір планувальника вводу-виводу Linux

Я прочитав, що нібито можливо змінити планувальник вводу-виводу для певного пристрою на запущеному ядрі, написавши в / sys / block / [диск] / черга / планувальник. Наприклад, я бачу в своїй системі:

anon@anon:~$ cat /sys/block/sda/queue/scheduler 
noop anticipatory deadline [cfq] 

що за замовчуванням цілком справедливий планувальник черг. Мені цікаво, чи є користь від включення всіх чотирьох планувальників у моє власне ядро. Здавалося б, немає великого сенсу складати більше одного планувальника, якщо ядро ​​не є достатньо розумним, щоб вибрати правильний планувальник для правильного обладнання, зокрема планувальник `` noop '' для флеш-накопичувачів та один з інших для традиційного жорсткий диск.

Чи це так?

Як задокументовано /usr/src/linux/Documentation/block/switching-sched.txt, планувальник вводу-виводу на будь-якому конкретному блочному пристрої може бути змінений під час виконання. Можливо, є деяка затримка, оскільки всі попередні запити планувальника змиваються перед тим, як використовувати новий планувальник, але його можна змінити без проблем, навіть коли пристрій інтенсивно використовується.

# cat /sys/block/hda/queue/scheduler
noop deadline [cfq]
# echo anticipatory > /sys/block/hda/queue/scheduler
# cat /sys/block/hda/queue/scheduler
noop [deadline] cfq

В ідеалі був би єдиний планувальник, який би задовольнив усі потреби. Здається, це ще не існує. Ядро часто не має достатніх знань, щоб вибрати найкращий планувальник для вашого навантаження:

• noop часто є найкращим вибором для блокованих пристроїв із підтримкою пам'яті (наприклад, дисків) та інших необертальних носіїв (флеш), коли спроба перепланувати введення-виведення - марне витрачання ресурсів
• deadline це легкий планувальник, який намагається жорстко обмежити затримку
• cfq намагається підтримувати загальносистемну справедливість пропускної здатності вводу-виводу

За замовчуванням було anticipatoryтривалий час, і він отримав багато налаштувань, але був видалений у 2.6.33 (початок 2010 р.). cfqстав за замовчуванням деякий час тому, оскільки його продуктивність розумна, а справедливість є хорошою метою для багатокористувацьких систем (і навіть однокористувацьких робочих столів). Для деяких сценаріїв - бази даних часто використовуються в якості прикладів, так як вони , як правило, вже мають свої власні шаблони планування своєрідна і доступ, і часто є найбільш важливою послугою (так , хто піклується про справедливість?) - anticipatoryмає довгу історію перебудовується для найкращої ефективності цих робочих навантажень і deadlineдуже швидко передає всі запити на базовий пристрій.

Можна використовувати правило udev, щоб дозволити системі приймати рішення щодо планувальника на основі деяких характеристик hw.
Приклад правила udev для твердотільних накопичувачів та інших дисків, що не обертаються, може виглядати так

# set noop scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

всередині нового файлу правил udev (наприклад, /etc/udev/rules.d/60-ssd-scheduler.rules). Ця відповідь базується на вікі debian

Щоб перевірити, чи використовуватимуть ssd диски правило, можна заздалегідь перевірити атрибут тригера:

for f in /sys/block/sd?/queue/rotational; do printf "$f "; cat $f; done

Мета того, щоб ядро ​​підтримувало різні, полягає в тому, що ви можете спробувати їх без перезавантаження; потім ви можете запустити тестові робочі навантаження через sytsem, виміряти продуктивність, а потім зробити це стандартним для вашого додатка.

На сучасному серверному обладнанні корисним виявляється лише той, який відповідає noop. Інші здаються повільнішими в моїх тестах.

Ви можете встановити це під час завантаження, додавши параметр "elevator" до cmdline ядра (наприклад, у grub.cfg)

Приклад:

elevator=deadline

Це зробить "кінцевий термін" типовим планувальником вводу-виводу для всіх блокових пристроїв.

Якщо ви хочете запитати або змінити планувальник після завантаження системи або хочете використовувати інший планувальник для певного блочного пристрою, я рекомендую встановити та використовувати інструмент ioschedset, щоб зробити це простішим.

https://github.com/kata198/ioschedset

Якщо ви користуєтеся Archlinux, це доступно в aur:

https://aur.archlinux.org/packages/ioschedset

Ось приклад використання:

# Get i/o scheduler for all block devices
[username@hostname ~]$ io-get-sched
sda:    bfq
sr0:    bfq

# Query available I/O schedulers
[username@hostname ~]$ io-set-sched --list
mq-deadline kyber bfq none

# Set sda to use "kyber"
[username@hostname ~]$ io-set-sched kyber /dev/sda
Must be root to set IO Scheduler. Rerunning under sudo...

[sudo] password for username:
+ Successfully set sda to 'kyber'!

# Get i/o scheduler for all block devices to assert change
[username@hostname ~]$ io-get-sched
sda:    kyber
sr0:    bfq

# Set all block devices to use 'deadline' i/o scheduler
[username@hostname ~]$ io-set-sched deadline
Must be root to set IO Scheduler. Rerunning under sudo...

+ Successfully set sda to 'deadline'!
+ Successfully set sr0 to 'deadline'!

# Get the current block scheduler just for sda
[username@hostname ~]$ io-get-sched sda
sda:    mq-deadline

Використання повинно бути зрозумілим. Інструменти автономні і вимагають лише bash.

Сподіваюся, це допомагає!

EDIT: Застереження, це сценарії, які я написав.

Ядро Linux не змінює автоматично планувальник введення-виведення під час виконання. Під цим я маю на увазі, що ядро ​​Linux, станом на сьогодні, не може автоматично вибирати "оптимальний" планувальник залежно від типу пристрою вторинного сховища. Під час запуску або під час виконання можна змінити планувальник введення-виведення вручну .

Планувальник за замовчуванням вибирається під час запуску на основі вмісту у файлі, розташованому за адресою /linux-2.6 /block/Kconfig.iosched . Однак можна змінити планувальник вводу-виводу під час виконання, echoввівши дійсне ім'я планувальника у файл, що знаходиться за адресою / sys / block / [DEV] / черга / планувальник. Наприклад,echo deadline > /sys/block/hda/queue/scheduler