Ladění plánovače I/O v Linuxu: mq-deadline, none a BFQ

Plánovač I/O v Linuxu určuje pořadí, v jakém požadavky na čtení a zápis dorazí k vašemu úložnému zařízení, a správná volba závisí téměř výhradně na vašem hardwaru. Použijte none pro NVMe, mq-deadline pro SSD a HDD s rozhraním SATA, na kterých běží smíšené pracovní zátěže, a bfq pokud potřebujete zabránit tomu, aby jeden proces omezoval ostatní. Tato příručka popisuje, jak fungují tři hlavní plánovače, jak je přizpůsobit vašemu pracovnímu zatížení a jak je vyladit a ověřit výsledek.

Pokud chcete před čtením praktický návod, toto video pokrývá základy přepínání a testování plánovačů z terminálu.

Jak se liší mq-deadline, none a BFQ

Každý plánovač zpracovává požadavky pomocí jiné strategie. Znalost jejich rozdílů vám umožní vybrat si záměrně, místo toho, abyste spouštěli to, co jádro vybralo při startu.

mq-deadline

Plánovač mq-deadline plánovač zajišťuje, že žádný požadavek nečeká donekonečna. Udržuje oddělené seřazené fronty pro čtení a zápis, řadí je podle logické blokové adresy (LBA), aby zkrátil dobu vyhledávání, a vynucuje časové limity: ve výchozím nastavení 500 ms pro čtení a 5 sekund pro zápis. Když požadavek dosáhne svého časového limitu, přeskočí na začátek fronty.

Čtení má přednost před zápisem, protože čtení obvykle blokuje aplikaci, zatímco zápis je zpracováván asynchronně. Aby se zabránilo úplnému zastavení zápisu, plánovač po stanoveném počtu čtení zpracuje dávku zpožděných zápisů. Výsledkem je konzistentní nízká latence, díky čemuž se tento plánovač skvěle hodí pro databázové servery a jakékoli pracovní zatížení, které kombinuje čtení a zápis.

none

Plánovač none plánovač nedělá téměř nic. Předává požadavky přímo zařízení v pořadí First-In-First-Out, bez přeskupování, slučování nebo stanovení priorit. To vyhovuje moderním diskům NVMe, které spravují své vlastní interní fronty a mohou sledovat desítky tisíc požadavků v procesu najednou. Odstranění softwarové plánovací vrstvy poskytuje nejkratší možnou cestu z aplikace k zařízení, což je přesně to, co vyžadují úlohy NVMe s vysokou propustností.

Hákem je, že to funguje pouze tehdy, když hardware dokáže sám inteligentně plánovat. U pevných disků nebo SSD disků SATA s malými frontami přeskočení softwarového přeskupování obvykle zhoršuje výkon, nikoli zlepšuje.

BFQ

BFQ (Budget Fair Queuing) klade na první místo spravedlnost. Místo časových úseků přiděluje každému procesu rozpočet měřený v diskových sektorech. Velké sekvenční čtečky dostávají větší rozpočty, aby se udržela vysoká propustnost, zatímco úkoly citlivé na latenci dostávají menší rozpočty, aby byly obslouženy rychle, a zpětná vazba upravuje rozpočty během běhu.

BFQ udržuje interaktivní úlohy responzivní i při velkém zatížení, takže přehrávání videa nebo dotaz do databáze zůstává plynulé, zatímco na pozadí probíhá přenos velkého souboru. Tato spravedlnost stojí výkon procesoru. Jeho režie na jeden požadavek je zhruba 1,9 mikrosekundy, což je asi třikrát více než u mq-deadline, a na pomalejším jádru ARM tato režie omezuje propustnost hluboko pod úroveň, které stejný plánovač dosahuje na rychlém čipu x86. Na serverech, kde záleží nejvíce na hrubé propustnosti a efektivitě CPU, je tento kompromis těžko ospravedlnitelný.

Výběr správného plánovače pro vaše pracovní zatížení

O správném plánovači rozhodují dvě věci: váš úložný hardware a vzorec přístupu vaší aplikace. Začněte s hardwarem. Pokud zařízení již požadavky přeskupuje, jako například disk NVMe s vhodným firmwarem, softwarové plánování pouze zvyšuje zátěž, takže none vyhrává. U rotujících pevných disků, kde dominuje doba vyhledávání, softwarové přeskupování snižuje latenci, takže mq-deadline nebo bfq jsou lepší volbou. SSD disky SATA se nacházejí někde uprostřed: jsou rychlejší než pevné disky, ale nemají hluboké fronty jako NVMe, což je místo, kde mq-deadline se hodí.

Stejná logika platí, když za vás již plánování provádí něco jiného. Hostované virtuální stroje na virtio-blk spoléhají na hostitele při plánování I/O a hardwarové řadiče RAID s write-back cache optimalizují své vlastní řazení. V obou případech none se tak zabrání dvojímu zatížení.

Druhým faktorem je vzorec přístupu. Databáze provádějící tisíce náhodných čtení 4K za sekundu nemá nic společného s úlohou trénování streamující velké sekvenční bloky z pole NVMe a vyžadují odlišné plánovače. Níže uvedená tabulka přiřazuje běžné pracovní zátěže k výchozímu bodu.

Je tu jedna výjimka, kterou stojí za to zmínit. I u NVMe, pokud je pro vás důležitá latence na konci (tail latency) na p99 nebo p999, například ve finančních systémech, mq-deadline může porazit none vynucením přísných termínů a zabráněním občasným zpožděným požadavkům.

Změna a ladění parametrů plánovače

Jak přepínání plánovačů, tak ladění jejich parametrů probíhá prostřednictvím sysfs, přičemž k otestování změny není nutné restartovat systém.

Přepnutí aktivního plánovače

Zkontrolujte, co je k dispozici pro dané zařízení, přičemž hodnota v závorkách je aktivní:

cat /sys/block/sda/queue/scheduler

Přepněte na jiný plánovač za běhu. Změna se projeví okamžitě, ale po restartu se ztratí:

echo bfq | sudo tee /sys/block/sda/queue/scheduler

Pokud bfq není v seznamu, nejprve načtěte modul:

sudo modprobe bfq

Chcete-li, aby volba byla trvalá, použijte pravidlo udev namísto starého elevator= parametr jádra, který již v RHEL 9 a podobných verzích plánovač nemění. Toto pravidlo nastaví mq-deadline pro všechny nerotační disky SCSI v /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"

Znovu načtěte a použijte jej bez restartu:

sudo udevadm control --reload-rules && sudo udevadm trigger

Na systémech založených na RHEL plní profily TuneD stejnou funkci prostřednictvím systémových profilů namísto pravidel pro jednotlivá zařízení.

Parametry, které stojí za vyladění

Každý plánovač zpřístupňuje své nastavitelné parametry v /sys/block/<device>/queue/iosched/. Pro mq-deadlinejsou hlavními pákami termíny. Databáze citlivé na latenci na SATA SSD těží z kratších termínů:

echo 100 | sudo tee /sys/block/sda/queue/iosched/read_expire
echo 1000 | sudo tee /sys/block/sda/queue/iosched/write_expire

U bfq systémů s vysokou propustností zvyšuje deaktivace heuristiky latence propustnost:

echo 0 | sudo tee /sys/block/sda/queue/iosched/low_latency
echo 0 | sudo tee /sys/block/sda/queue/iosched/slice_idle

Pro sdílený hosting se BFQ dobře kombinuje s cgroups v2. Přiřazení io.weight hodnot umožňuje například přidělit databázovému procesu desetkrát větší podíl I/O než zálohovacímu úloze, takže práce na pozadí nemůže přehlušit interaktivní provoz. Ať už změníte cokoli, vyšší náklady BFQ na jeden požadavek se sčítají na systémech s vysokým zatížením CPU a vysokým počtem IOPS, proto před provedením změn proveďte benchmark.

Ověření výkonu po ladění

Vždy zaznamenejte výchozí stav, než něco změníte. Bez něj nemáte jak zjistit, zda daná úprava pomohla.

fio je standardní nástroj pro tento účel. Reprodukuje specifické vzorce pracovní zátěže prostřednictvím velikosti bloku, hloubky fronty a nastavení I/O enginu. Vždy použijte --direct=1 , aby se obešla stránková cache a měřila přímo plánovač a zařízení namísto čtení z cache. Přizpůsobte test skutečnému pracovnímu zatížení:

Spusťte stejný test s iodepth hodnotách od 1 do 256, abyste zjistili bod nasycení zařízení, hloubku, kde IOPS přestávají stoupat a dochází k nárůstům latence. Pro živé monitorování po změně iostat -x 1 zprávy o metrikách, na kterých záleží: r_await a w_await pro latenci dokončení čtení a zápisu, aqu-sz pro průměrnou hloubku fronty a %util pro využití zařízení. Pokud %util se blíží 100 procentům, je limitem hardware a žádná změna plánovače nepomůže.

Chcete-li oddělit náklady na software od nákladů na hardware, spusťte blktrace s btt. Rozdělí to latenci na Q2D, čas strávený ve frontě softwaru, a D2C, čas, který zařízení potřebuje k vyřízení požadavku. Pokud dominuje Q2D, je vaším úzkým hrdlem plánovač. Pokud dominuje D2C, je jím hardware.

Při čtení výsledků je třeba mít na paměti jednu věc: volba plánovače většinou ovlivňuje konec distribuce latence, nikoli medián. Přechod z none na mq-deadline na NVMe může posunout medián latence o několik mikrosekund nahoru, zatímco latence p99 a p999 se sníží na polovinu. U služeb pro uživatele vázaných smlouvami SLA se tento kompromis téměř vždy vyplatí, a proto je smyslem tohoto cvičení měření latence na konci distribuce, nikoli průměrné propustnosti.

Výběr správného plánovače

Ladění plánovače spočívá v přizpůsobení algoritmu hardwaru a vzoru přístupu a následném ověření pomocí měření. Stručně řečeno:

• NVMe: použijte none a nechte fronty spravovat firmwarem.
• SSD a HDD s rozhraním SATA se smíšeným I/O: použijte mq-deadline pro předvídatelnou latenci.
• Sdílené nebo multi-tenantní hosty: použijte bfq , aby jedno pracovní zatížení neomezovalo ostatní.
• Sledujte latenci na konci, ne medián: změny plánovače se projeví na p99 a p999, takže to je to, co je třeba měřit.
• Zajistěte trvalost: použijte pravidla udev nebo TuneD, nikdy parametr dead elevator= .

Chcete-li z jakéhokoli plánovače vytěžit maximum, potřebujete hardware, který s ním udrží krok. Pokud potřebujete servery s NVMe navržené pro úlohy s vysokou propustností a nízkou latencí, prozkoumejte možnosti VPS od FDC.