Justering av Linux I/O-schemaläggare: mq-deadline, none och BFQ

Linux I/O-schemaläggaren bestämmer i vilken ordning läs- och skrivförfrågningar når din lagringsenhet, och det rätta valet beror nästan helt på din hårdvara. Använd none för NVMe, mq-deadline för SATA SSD-enheter och HDD-enheter som kör blandade arbetsbelastningar, och bfq när du behöver förhindra att en process tar resurser från de andra. Den här guiden beskriver hur de tre huvudsakliga schemaläggarna fungerar, hur du matchar en till din arbetsbelastning och hur du finjusterar och verifierar resultatet.

Om du vill ha en praktisk genomgång innan du läser vidare täcker den här videon grunderna i att byta och testa schemaläggare från terminalen.

Hur mq-deadline, none och BFQ skiljer sig åt

Varje schemaläggare hanterar förfrågningar med olika strategier. Att veta hur de skiljer sig åt gör att du kan välja medvetet istället för att köra det som kärnan valde vid uppstart.

mq-deadline

Schedulern mq-deadline schemaläggaren ser till att ingen begäran väntar i evighet. Den håller separata sorterade köer för läsningar och skrivningar, ordnar dem efter logisk blockadress för att minska söktiden och tillämpar tidsgränser: 500 ms för läsningar och 5 sekunder för skrivningar som standard. När en begäran når sin tidsgräns hoppar den fram till början av kön.

Läsningar har prioritet framför skrivningar, eftersom läsningar vanligtvis blockerar applikationen medan skrivningar hanteras asynkront. För att förhindra att skrivningar helt stängs ute, hanterar schemaläggaren en batch med försenade skrivningar efter ett visst antal läsningar. Resultatet är en konsekvent låg latens, vilket gör den mycket lämplig för databasservrar och alla arbetsbelastningar som blandar läsningar och skrivningar.

ingen

Schemaläggaren none schemaläggaren gör nästan ingenting. Den vidarebefordrar förfrågningar direkt till enheten i First-In-First-Out-ordning, utan omordning, sammanslagning eller prioritering. Det passar moderna NVMe-enheter, som hanterar sina egna interna köer och kan spåra tiotusentals pågående förfrågningar samtidigt. Att ta bort det mjukvarubaserade schemaläggningslagret ger den kortast möjliga vägen från applikation till enhet, vilket är precis vad NVMe-arbetsbelastningar med hög genomströmning kräver.

Haken är att detta bara fungerar när hårdvaran kan schemalägga intelligent på egen hand. På HDD-enheter eller SATA-SSD-enheter med korta köer gör det vanligtvis prestandan sämre, inte bättre, att hoppa över omordning i programvaran.

BFQ

BFQ (Budget Fair Queuing) sätter rättvisa i första rummet. Istället för tidsintervall ger det varje process en budget mätt i disksektorer. Stora sekventiella läsare får större budgetar för att hålla genomströmningen uppe, medan latenskänsliga uppgifter får mindre budgetar så att de hanteras snabbt, och en återkopplingsslinga justerar budgetarna under körning.

BFQ håller interaktiva uppgifter responsiva även under tung belastning, så att videouppspelning eller en databasfråga förblir smidig medan en stor filöverföring körs i bakgrunden. Denna rättvisa kostar CPU. Dess overhead per begäran är ungefär 1,9 mikrosekunder, ungefär tre gånger så mycket som mq-deadline, och på en långsammare ARM-kärna begränsar den overheaden genomströmningen till långt under vad samma schemaläggare når på en snabb x86-chip. På servrar där ren genomströmning och CPU-effektivitet är viktigast är den avvägningen svår att motivera.

Anpassa schemaläggaren till din arbetsbelastning

Två saker avgör vilken schemaläggare som är rätt: din lagringshårdvara och din applikations åtkomstmönster. Börja med hårdvaran. Om enheten redan omordnar förfrågningar, som en NVMe-enhet med lämplig firmware, tillför mjukvaruschemaläggning bara extra belastning, så none vinner. På roterande hårddiskar, där söktiden dominerar, minskar omordning via programvara latensen, så mq-deadline eller bfq är de bättre valen. SATA-SSD-enheter ligger mittemellan: snabbare än HDD-enheter men utan NVMe:s djupa köer, vilket är där mq-deadline passar in.

Samma logik gäller när något annat redan sköter schemaläggningen åt dig. Gäst-VM:er på virtio-blk förlitar sig på värden för att schemalägga I/O, och hårdvaru-RAID-kontroller med write-back-cache optimerar sin egen ordning. I båda fallen none undviks att betala för arbetet två gånger.

Åtkomstmönster är den andra faktorn. En databas som utför tusentals slumpmässiga 4K-läsningar per sekund har ingenting gemensamt med ett träningsjobb som strömmar stora sekventiella block från en NVMe-array, och de kräver olika schemaläggare. Tabellen nedan kopplar vanliga arbetsbelastningar till en utgångspunkt.

Det finns ett undantag som är värt att nämna. Även på NVMe, om svanslatens vid p99 eller p999 är den mätvärde du bryr dig om, till exempel i finansiella system, mq-deadline kan slå none genom att upprätthålla strikta tidsfrister och förhindra enstaka försenade förfrågningar.

Ändra och justera schemaläggningsparametrar

Både byte av schemaläggare och justering av deras parametrar sker via sysfs, utan att omstart krävs för att testa en ändring.

Byta aktiv schemaläggare

Kontrollera vad som är tillgängligt för en enhet, där värdet inom parentes är det aktiva:

cat /sys/block/sda/queue/scheduler

Byt till en annan schemaläggare under körning. Detta träder i kraft omedelbart men kvarstår inte efter en omstart:

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

Om bfq inte finns med i listan, ladda modulen först:

sudo modprobe bfq

För att göra ett val beständigt, använd en udev-regel istället för den gamla elevator= kärnparametern, som inte längre ändrar schemaläggaren på RHEL 9 och liknande versioner. Denna regel ställer in mq-deadline för alla icke-roterande SCSI-diskar i /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"

Ladda om och tillämpa den utan omstart:

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

På RHEL-baserade system gör TuneD-profiler samma sak genom systemomfattande profiler istället för regler per enhet.

Parametrar som är värda att justera

Varje schemaläggare exponerar sina inställningsbara parametrar under /sys/block/<device>/queue/iosched/. För mq-deadlineär tidsgränserna de viktigaste reglagen. Latenskänsliga databaser på SATA-SSD:er gynnas av kortare tidsgränser:

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

För bfq på system med hög genomströmning ökar genomströmningen om man inaktiverar latensheuristiken:

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

För delad hosting fungerar BFQ bra tillsammans med cgroups v2. Genom att tilldela io.weight värden kan du till exempel ge en databasprocess tio gånger så stor I/O-andel som ett säkerhetskopieringsjobb, så att bakgrundsarbete inte kan överrösta interaktiv trafik. Oavsett vad du ändrar, summeras BFQ:s högre kostnad per begäran på CPU-bundna system med hög IOPS, så gör en prestandatest innan du genomför ändringen.

Verifiera prestanda efter justering

Registrera alltid en baslinje innan du ändrar något. Utan den har du inget sätt att avgöra om en justering har hjälpt.

fio är standardverktyget för detta. Det återskapar specifika arbetsbelastningsmönster genom inställningar för blockstorlek, ködjup och I/O-motor. Använd alltid --direct=1 så att det går förbi sidcachen och mäter schemaläggaren och enheten direkt istället för cachade läsningar. Anpassa testet till den verkliga arbetsbelastningen:

Kör samma test över iodepth värden från 1 till 256 för att hitta enhetens mättnadspunkt, det djup där IOPS slutar stiga och latensen ökar kraftigt. För liveövervakning efter en ändring iostat -x 1 rapporterar de mätvärden som är viktiga: r_await och w_await för latens vid slutförd läsning och skrivning, aqu-sz för genomsnittligt ködjup, och %util för enhetsutnyttjande. När %util ligger nära 100 procent är hårdvaran begränsningen och ingen ändring av schemaläggaren hjälper.

För att skilja mjukvarukostnaden från hårdvarukostnaden, kör blktrace med btt. Det delar upp latensen i Q2D, tiden som spenderas i mjukvarukön, och D2C, tiden det tar för enheten att hantera begäran. Om Q2D dominerar är schemaläggaren din flaskhals. Om D2C dominerar är det hårdvaran.

En sak att tänka på när du läser resultaten: valet av schemaläggare påverkar främst svansen av latensfördelningen, inte medianen. Att byta från none till mq-deadline på NVMe kan höja medianlatensen med några mikrosekunder samtidigt som p99- och p999-latensen halveras. För användarorienterade tjänster som är bundna av SLA:er är den avvägningen nästan alltid värd det, vilket är anledningen till att mätning av latensens svans, inte genomsnittlig genomströmning, är poängen med övningen.

Att välja rätt schemaläggare

Att finjustera schemaläggaren handlar om att anpassa algoritmen till hårdvaran och åtkomstmönstret, och sedan verifiera detta med mätningar. Kortfattat:

• NVMe: använd none och låt firmware sköta köhanteringen.
• SATA SSD-enheter och HDD-enheter med blandad I/O: använd mq-deadline för förutsägbar latens.
• Delade eller multitenant-värdar: använd bfq för att förhindra att en arbetsbelastning tar resurser från de övriga.
• Mät svanslatens, inte median: schemaläggarens förändringar syns vid p99 och p999, så det är det man ska mäta.
• Gör det beständigt: använd udev-regler eller TuneD, aldrig den döda elevator= .

Att få ut det mesta av vilken schemaläggare som helst börjar med hårdvara som hänger med. Om du behöver NVMe-baserade servrar byggda för arbetsbelastningar med hög genomströmning och låg latens, utforska FDC:s VPS-alternativ.