Wybieranie harmonogramu we / wy systemu Linux

Czytałem, że podobno możliwa jest zmiana harmonogramu I / O dla konkretnego urządzenia w działającym jądrze, zapisując do / sys / block / [dysk] / queue / schedule. Na przykład widzę w moim systemie:

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

że domyślnym jest całkowicie sprawiedliwy harmonogram kolejkowania. Zastanawiam się, czy włączenie wszystkich czterech programów planujących do mojego niestandardowego jądra ma sens. Wydawałoby się, że nie ma sensu skompilować więcej niż jednego harmonogramu, chyba że jądro jest wystarczająco inteligentne, aby wybrać odpowiedni harmonogram dla odpowiedniego sprzętu, w szczególności harmonogram „noop” dla dysków flash i jeden z pozostałych dla tradycyjnego twardy dysk.

Czy tak jest?

Jak udokumentowano w /usr/src/linux/Documentation/block/switching-sched.txt, harmonogram I / O na dowolnym urządzeniu blokowym można zmienić w czasie wykonywania. Może wystąpić pewne opóźnienie, ponieważ wszystkie żądania poprzedniego programu planującego są opróżniane przed uruchomieniem nowego harmonogramu, ale można je zmienić bez problemów, nawet gdy urządzenie jest intensywnie używane.

# 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

Idealnie byłoby, gdyby istniał jeden program planujący spełniający wszystkie potrzeby. Wydaje się, że jeszcze nie istnieje. Jądro często nie ma wystarczającej wiedzy, aby wybrać najlepszy harmonogram dla Twojego obciążenia:

• noop jest często najlepszym wyborem dla urządzeń blokowych z obsługą pamięci (np. ramdysków) i innych nośników nieobrotowych (flash), w których zmiana harmonogramu operacji we / wy jest stratą zasobów
• deadline to lekki program planujący, który próbuje nałożyć sztywny limit opóźnienia
• cfq próbuje zachować sprawiedliwość przepustowości we / wy w całym systemie

Wartość domyślna istniała anticipatoryprzez długi czas i otrzymywała wiele zmian, ale została usunięta w wersji 2.6.33 (początek 2010 r.). cfqstał się domyślny jakiś czas temu, ponieważ jego wydajność jest rozsądna, a uczciwość jest dobrym celem dla systemów wielu użytkowników (a nawet komputerów stacjonarnych z jednym użytkownikiem). Dla niektórych scenariuszach - bazy danych są często używane jako przykłady, ponieważ mają tendencję do już mają swoje osobliwe i planowania dostępu wzory, a często są najbardziej istotne usługa (więc kto dba o uczciwości?) - anticipatoryma długą historię bycia regulowanej aby uzyskać najlepszą wydajność przy tych obciążeniach i deadlinebardzo szybko przekazuje wszystkie żądania do urządzenia bazowego.

Możliwe jest użycie reguły udev, aby pozwolić systemowi decydować o harmonogramie na podstawie niektórych cech hw.
Przykładowa reguła udev dla dysków SSD i innych dysków nieobrotowych może wyglądać tak

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

wewnątrz nowego pliku reguł udev (np /etc/udev/rules.d/60-ssd-scheduler.rules.). Ta odpowiedź jest oparta na wiki debiana

Aby sprawdzić, czy dyski SSD użyją reguły, można z wyprzedzeniem sprawdzić atrybut wyzwalacza:

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

Celem posiadania obsługi różnych jąder jest możliwość wypróbowania ich bez ponownego uruchamiania; możesz następnie uruchamiać obciążenia testowe za pośrednictwem sytsem, mierzyć wydajność, a następnie ustawić je jako standardowe dla swojej aplikacji.

Na nowoczesnym sprzęcie serwerowym tylko ten noop wydaje się w ogóle przydatny. Inne wydają się wolniejsze w moich testach.

Możesz to ustawić podczas uruchamiania, dodając parametr „winda” do cmdline jądra (np. W grub.cfg)

Przykład:

elevator=deadline

Spowoduje to, że „ostateczny termin” stanie się domyślnym harmonogramem I / O dla wszystkich urządzeń blokowych.

Jeśli chcesz zapytać lub zmienić harmonogram po uruchomieniu systemu lub chcesz użyć innego harmonogramu dla określonego urządzenia blokowego, zalecamy zainstalowanie i użycie narzędzia ioschedset, aby to ułatwić.

https://github.com/kata198/ioschedset

Jeśli jesteś na Archlinux, jest dostępny w aur:

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

Kilka przykładów użycia:

# 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

Sposób użycia powinien być oczywisty. Narzędzia są samodzielne i wymagają tylko basha.

Mam nadzieję że to pomoże!

EDYCJA: Uwaga, to są skrypty, które napisałem.

Jądro Linuksa nie zmienia automatycznie harmonogramu IO w czasie wykonywania. Rozumiem przez to, że jądro Linuksa na dzień dzisiejszy nie jest w stanie automatycznie wybrać „optymalnego” harmonogramu w zależności od typu urządzenia pamięci dodatkowej. Podczas uruchamiania lub w czasie wykonywania możliwa jest ręczna zmiana harmonogramu We / Wy .

Domyślny harmonogram jest wybierany podczas uruchamiania na podstawie zawartości pliku znajdującego się w /linux-2.6 /block/Kconfig.iosched . Istnieje jednak możliwość zmiany programu planującego IO w czasie wykonywania poprzez echowprowadzenie prawidłowej nazwy programu planującego do pliku znajdującego się w / sys / block / [DEV] / queue / schedule. Na przykład,echo deadline > /sys/block/hda/queue/scheduler