Wybieranie harmonogramu we / wy systemu Linux

82

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?

Robert S. Barnes
źródło

Odpowiedzi:

109

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.

ephemient
źródło
1
Świetne informacje, dzięki! Ale moje podstawowe pytanie nadal pozostaje bez odpowiedzi, czy podłączę pendrive lub mój netbook z dysku flash, ponieważ jego główny dysk jest wystarczająco inteligentny, aby wybrać noop zamiast domyślnego cfq? Czy może całkowicie zależy ode mnie, czy zrobię to ręcznie?
Robert S. Barnes
3
Możesz skonfigurować jądro, aby domyślnie korzystało z innego harmonogramu. Byłoby mądrze automatycznie używać go noopna nośnikach nieobrotowych, ale jądro nie ma takiej funkcjonalności. W pewnym sensie wykrywa nośniki nieobrotowe, ale nie jest niezawodne, ponieważ niektóre dyski zgłaszają się błędnie, a mimo to nie są jeszcze połączone z kodem harmonogramu we / wy.
ephemient
8
Możesz dodać reguły udev, aby zdefiniować harmonogram w oparciu o charakterystykę urządzenia, tak jak na wiki debian ( wiki.debian.org/SSDOptimization#Low-Latency_IO-Scheduler ) # ustaw harmonogram terminów dla dysków nieobrotowych ACTION == "add | change ", KERNEL ==" sd [az] ", ATTR {queue / rotational} ==" 0 ", ATTR {queue / scheduleer} =" deadline "
Dani_l
@Dani_l Powinieneś to rozwinąć i dodać jako odpowiedź.
Robert S. Barnes
1
Czy istnieje sposób, aby zmienić to dla wszystkich dysków jednocześnie w czasie wykonywania? Podobnie ustawianie domyślnego harmonogramu przez parametr wiersza poleceń jądra „winda”. Dzięki.
SkyRaT
20

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
Dani_l
źródło
Świetna odpowiedź na temat automatyzacji wykrywania nośników nieobrotowych i stosowania harmonogramu IO tylko do nich. Termin zalecany jest nie tylko w przypadku nośników nieobrotowych. Oracle zaleca harmonogram we / wy dla obciążeń bazy danych. To zalecenie Oracle prawdopodobnie wynika z faktu, że termin może obsługiwać lepsze synchroniczne zapisy niż inne programy planujące IO. Poszukaj na przykład / sys / block / sdX / queue / iosched / writes_starved "deadline" planista do dostrajania (nie ma takiego dostrajalnego dla odczytów). Bazy danych mogą mieć słabą wydajność, jeśli ich synchroniczne zapisy powtórne nie przebiegają szybko.
Tagar
7

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.

MarkR
źródło
Jak właściwie to zmienić w czasie wykonywania?
Robert S. Barnes
Wydajność noop w stosunku do innych programów planujących w dużym stopniu zależy od sprzętu i określonego obciążenia. Z ciekawości, jakie dyski, kontrolery i testy uruchomiłeś?
ephemient
1
Tak, noop jest dobry, gdy masz inteligentne kontrolery RAID i inne rzeczy, w których wie więcej niż jądro o najlepszych wzorcach dostępu. Termin też nie jest zły.
Zan Lynx
1
Jest to dla mnie ćwiczenie czysto szkoleniowe, w którym próbuję skonfigurować możliwie najmniejsze i najszybciej uruchamiające się jądro, które zapewnia wszystkie funkcje, których potrzebuję na moim laptopie. Przejrzałem zarówno „Linux Kernel Development”, jak i „Essential Linux Device Drivers” i nie znalazłem satysfakcjonującej odpowiedzi na to pytanie, jak sprytne jest jądro w wybieraniu harmonogramu w czasie wykonywania, czy też zawsze używa domyślnego, chyba że ręcznie ustawiłeś to na coś innego?
Robert S. Barnes
ephemient> na kontrolerach DELL PERC, a także na DELL Powervault MD3000. Wydawało się lepsze niż domyślne (CFQ) na obu.
MarkR
0

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.

Tim Savannah
źródło
-3

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

KZcoding
źródło
8
Nie rozumiem, dlaczego ta odpowiedź zasługuje na tyle głosów przeciw. W rzeczywistości nie jest to błędne.
Przygnębiony