it-swarm.com.ru

Выбор планировщика ввода-вывода Linux

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

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

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

Это тот случай?

80
Robert S. Barnes

Как описано в /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 часто является лучшим выбором для блочных устройств с поддержкой памяти (например, ramdisks) и других невращающихся носителей (флэш), где попытка перепланировать ввод-вывод является пустой тратой ресурсов
  • deadline - это легкий планировщик, который пытается установить жесткое ограничение задержки
  • cfq пытается поддерживать общесистемную справедливость пропускной способности ввода/вывода

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

107
ephemient

Можно использовать правило 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 Wiki

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

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

Целью того, чтобы ядро ​​поддерживало разные, является то, что вы можете попробовать их без перезагрузки; Затем вы можете запустить тестовые рабочие нагрузки через систему, измерить производительность, а затем сделать ее стандартной для вашего приложения.

На современном оборудовании серверного уровня полезен только один. Другие, кажется, медленнее в моих тестах.

7
MarkR

Вы можете установить это при загрузке, добавив параметр "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
[[email protected] ~]$ io-get-sched
sda:    bfq
sr0:    bfq

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

# Set sda to use "kyber"
[[email protected] ~]$ 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
[[email protected] ~]$ io-get-sched
sda:    kyber
sr0:    bfq

# Set all block devices to use 'deadline' i/o scheduler
[[email protected] ~]$ 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
[[email protected] ~]$ io-get-sched sda
sda:    mq-deadline

Использование должно быть само за себя. Инструменты автономны и требуют только bash.

Надеюсь это поможет!

Правка: Отказ от ответственности, это сценарии, которые я написал.

0
Tim Savannah