Linux I/O-scheduler afstemmen: mq-deadline, none en BFQ

De Linux I/O-scheduler bepaalt de volgorde waarin lees- en schrijfverzoeken uw opslagapparaat bereiken, en de juiste keuze hangt bijna volledig af van uw hardware. Gebruik none voor NVMe, mq-deadline voor SATA SSD's en HDD's met gemengde workloads, en bfq wanneer u moet voorkomen dat één proces de andere processen uitput. Deze gids behandelt hoe de drie belangrijkste schedulers werken, hoe u er een kunt afstemmen op uw workload en hoe u deze kunt afstemmen en het resultaat kunt verifiëren.

Als u een praktische uitleg wilt voordat u verder leest, behandelt deze video de basisprincipes van het wisselen en testen van schedulers vanaf de terminal.

Hoe mq-deadline, none en BFQ van elkaar verschillen

Elke scheduler verwerkt verzoeken met een andere strategie. Als u weet hoe ze van elkaar verschillen, kunt u een weloverwogen keuze maken in plaats van gewoon te draaien wat de kernel bij het opstarten heeft gekozen.

mq-deadline

De mq-deadline scheduler zorgt ervoor dat geen enkel verzoek oneindig lang wacht. Hij houdt aparte, gesorteerde wachtrijen bij voor lees- en schrijfverzoeken, rangschikt deze op Logical Block Address om de zoektijd te verkorten, en dwingt deadlines af: standaard 500 ms voor leesverzoeken en 5 seconden voor schrijfverzoeken. Wanneer een verzoek zijn deadline bereikt, springt het naar de voorkant van de wachtrij.

Lezen heeft voorrang op schrijven, aangezien lezen de applicatie meestal blokkeert, terwijl schrijven asynchroon wordt afgehandeld. Om te voorkomen dat schrijven volledig wordt uitgesloten, verwerkt de scheduler een batch achterstallige schrijfverzoeken na een bepaald aantal leesverzoeken. Het resultaat is een consistent lage latentie, waardoor deze strategie zeer geschikt is voor databaseservers en elke workload die lezen en schrijven combineert.

geen

De none scheduler doet bijna niets. Hij geeft verzoeken rechtstreeks door aan het apparaat in First-In-First-Out-volgorde, zonder herschikking, samenvoeging of prioritering. Dat past bij moderne NVMe-schijven, die hun eigen interne wachtrijen beheren en tienduizenden lopende verzoeken tegelijk kunnen volgen. Het verwijderen van de softwarematige planningslaag zorgt voor de kortst mogelijke route van applicatie naar apparaat, wat precies is wat NVMe-workloads met hoge doorvoer nodig hebben.

Het addertje onder het gras is dat dit alleen werkt als de hardware zelfstandig intelligent kan plannen. Op HDD's of SATA SSD's met korte wachtrijen leidt het overslaan van softwareherordening meestal tot slechtere prestaties, niet tot betere.

BFQ

BFQ (Budget Fair Queuing) stelt eerlijkheid voorop. In plaats van tijdssegmenten krijgt elk proces een budget toegewezen dat wordt gemeten in schijfsectoren. Grote sequentiële lezers krijgen grotere budgetten om de doorvoer hoog te houden, terwijl latentiegevoelige taken kleinere budgetten krijgen zodat ze snel worden afgehandeld, en een feedbackloop past de budgetten tijdens het draaien aan.

BFQ zorgt ervoor dat interactieve taken zelfs onder zware belasting responsief blijven, zodat het afspelen van video of een databasequery soepel verloopt terwijl er op de achtergrond een grote bestandsoverdracht plaatsvindt. Die eerlijkheid kost CPU-vermogen. De overhead per verzoek is ongeveer 1,9 microseconden, ongeveer drie keer zoveel als die van mq-deadline, en op een langzamere ARM-kern beperkt die overhead de doorvoer tot ver onder wat dezelfde planner bereikt op een snelle x86-chip. Op servers waar ruwe doorvoer en CPU-efficiëntie het belangrijkst zijn, is die afweging moeilijk te rechtvaardigen.

Een scheduler afstemmen op uw werklast

Twee zaken bepalen de juiste scheduler: uw opslaghardware en het toegangspatroon van uw applicatie. Begin met de hardware. Als het apparaat verzoeken al herschikt, zoals een NVMe-schijf met geschikte firmware, voegt softwarematige planning alleen maar overhead toe, dus none wint. Op draaiende HDD's, waar zoektijd de boventoon voert, vermindert het herschikken door software de latentie, dus mq-deadline of bfq de betere keuzes. SATA SSD's zitten er tussenin: sneller dan HDD's maar zonder de diepe wachtrijen van NVMe, en dat is waar mq-deadline past.

Dezelfde logica geldt wanneer iets anders de planning al voor u regelt. Gast-VM's op virtio-blk vertrouwen op de host voor het plannen van I/O, en hardware-RAID-controllers met write-back-cache optimaliseren hun eigen volgorde. In beide gevallen none wordt voorkomen dat je dubbel voor het werk betaalt.

Het toegangspatroon is de tweede factor. Een database die duizenden willekeurige 4K-leesbewerkingen per seconde uitvoert, heeft niets gemeen met een trainingstaak die grote sequentiële blokken vanaf een NVMe-array streamt, en ze hebben verschillende schedulers nodig. De onderstaande tabel brengt veelvoorkomende workloads in kaart als uitgangspunt.

Er is één uitzondering die het vermelden waard is. Zelfs op NVMe, als de staartlatentie bij p99 of p999 de maatstaf is waar je om geeft, zoals in financiële systemen, mq-deadline kan none door strikte deadlines af te dwingen en het af en toe vertraagde verzoek te voorkomen.

Schedulerparameters wijzigen en afstemmen

Zowel het wisselen van schedulers als het afstemmen van hun parameters gebeurt via sysfs, waarbij geen herstart nodig is om een wijziging te testen.

De actieve scheduler wisselen

Controleer wat er beschikbaar is voor een apparaat, waarbij de waarde tussen haakjes de actieve is:

cat /sys/block/sda/queue/scheduler

Schakel tijdens de uitvoering over naar een andere scheduler. Dit heeft onmiddellijk effect, maar blijft niet behouden na een herstart:

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

Als bfq niet in de lijst staat, laad dan eerst de module:

sudo modprobe bfq

Om een keuze permanent te maken, gebruik je een udev-regel in plaats van de oude elevator= kernelparameter, die de scheduler niet meer wijzigt op RHEL 9 en vergelijkbare releases. Deze regel stelt mq-deadline voor alle niet-roterende SCSI-schijven in /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"

Laad deze opnieuw en pas hem toe zonder opnieuw op te starten:

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

Op op RHEL gebaseerde systemen doen TuneD-profielen hetzelfde via systeembrede profielen in plaats van regels per apparaat.

Parameters die het afstemmen waard zijn

Elke scheduler stelt zijn instelbare parameters beschikbaar onder /sys/block/<device>/queue/iosched/. Voor mq-deadlinezijn de deadlines de belangrijkste hefbomen. Latentiegevoelige databases op SATA SSD's hebben baat bij kortere deadlines:

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

Voor bfq op systemen met hoge doorvoer verhoogt het uitschakelen van de latentie-heuristieken de doorvoer:

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

Voor shared hosting werkt BFQ goed samen met cgroups v2. Door io.weight waarden kunt u bijvoorbeeld een databaseproces tien keer zoveel I/O-aandeel geven als een back-uptaak, zodat achtergrondwerk het interactieve verkeer niet kan overstemmen. Wat u ook wijzigt, de hogere kosten per verzoek van BFQ tellen op bij CPU-gebonden systemen met hoge IOPS, dus voer een benchmark uit voordat u de wijziging doorvoert.

Prestaties controleren na het afstemmen

Leg altijd een baseline vast voordat u iets wijzigt. Zonder deze baseline kunt u niet vaststellen of een aanpassing heeft geholpen.

fio is hiervoor de standaardtool. Het reproduceert specifieke werkbelastingpatronen via blokgrootte, wachtrijdiepte en I/O-engine-instellingen. Geef altijd --direct=1 zodat de paginacache wordt omzeild en de scheduler en het apparaat direct worden gemeten in plaats van gelezen uit de cache. Stem de test af op de werkelijke werklast:

Voer dezelfde test uit met iodepth waarden van 1 tot 256 om het verzadigingspunt van het apparaat te vinden, de diepte waar IOPS niet verder stijgt en de latentie piekt. Voor live monitoring na een wijziging iostat -x 1 rapporteert de statistieken die ertoe doen: r_await en w_await voor de voltooiingslatentie bij lezen en schrijven, aqu-sz voor de gemiddelde wachtrijdiepte, en %util voor apparaatgebruik. Wanneer %util dicht bij 100 procent ligt, is de hardware de beperkende factor en helpt geen enkele wijziging in de scheduler.

Om de softwarekosten te scheiden van de hardwarekosten, voer je blktrace uit met btt. Dit splitst de latentie op in Q2D, de tijd die in de softwarewachtrij wordt doorgebracht, en D2C, de tijd die het apparaat nodig heeft om het verzoek te verwerken. Als Q2D domineert, is de scheduler je bottleneck. Als D2C domineert, is dat de hardware.

Een ding om in gedachten te houden bij het lezen van de resultaten: de keuze van de scheduler bepaalt vooral de staart van de latentieverdeling, niet de mediaan. Overschakelen van none naar mq-deadline op NVMe kan de mediane latentie met een paar microseconden verhogen, terwijl de p99- en p999-latentie met de helft worden verminderd. Voor gebruikersgerichte diensten die gebonden zijn aan SLA's is die afweging bijna altijd de moeite waard. Daarom is het meten van de staartlatentie, en niet de gemiddelde doorvoer, het doel van de oefening.

De juiste scheduler kiezen

Bij het afstemmen van de scheduler gaat het erom het algoritme aan te passen aan de hardware en het toegangspatroon, en dit vervolgens te bewijzen met metingen. De korte versie:

• NVMe: gebruik none en laat de firmware de wachtrijen beheren.
• SATA SSD's en HDD's met gemengde I/O: gebruik mq-deadline voor voorspelbare latentie.
• Gedeelde of multi-tenant hosts: gebruik bfq om te voorkomen dat één workload de rest uitput.
• Let op de staartlatentie, niet op de mediaan: wijzigingen in de scheduler zijn zichtbaar bij p99 en p999, dus dat is wat je moet meten.
• Maak het persistent: gebruik udev-regels of TuneD, nooit de elevator= parameter.

Het maximale uit elke scheduler halen begint met hardware die het kan bijhouden. Als u NVMe-ondersteunde servers nodig hebt die zijn gebouwd voor workloads met hoge doorvoer en lage latentie, bekijk dan de VPS-opties van FDC.