Linux I/O ütemező hangolása: mq-deadline, none és BFQ

A Linux I/O ütemezője határozza meg, hogy az olvasási és írási kérések milyen sorrendben érkeznek a tárolóeszközhöz, és a megfelelő választás szinte teljes mértékben a hardvertől függ. Használja none az NVMe-hez, mq-deadline a vegyes terhelésű SATA SSD-k és HDD-k esetében, valamint bfq ha meg kell akadályoznia, hogy egy folyamat elvonja a forrásokat a többitől. Ez az útmutató bemutatja a három fő ütemező működését, hogyan válassza ki a munkaterheléséhez legmegfelelőbbet, valamint hogyan hangolja be és ellenőrizze az eredményt.

Ha olvasás előtt gyakorlati bemutatót szeretne, ez a videó bemutatja a terminálról történő ütemezőváltás és tesztelés alapjait.

Miben különböznek az mq-deadline, a none és a BFQ?

Minden ütemező más stratégiával kezeli a kéréseket. Ha tudjuk, miben különböznek egymástól, akkor tudatosan választhatunk, ahelyett, hogy azt futtatnánk, amit a rendszermag indításkor kiválasztott.

mq-deadline

Az mq-deadline ütemező gondoskodik arról, hogy egyetlen kérés se várjon a végtelenségig. Külön, rendezett sorokat tart fenn az olvasási és írási műveletekhez, logikai blokkcím (LBA) szerint rendezve őket a keresési idő csökkentése érdekében, és határidőket érvényesít: alapértelmezés szerint 500 ms az olvasáshoz és 5 másodperc az íráshoz. Amikor egy kérés elérte a határidejét, a sor elejére ugrik.

Az olvasási műveletek elsőbbséget élveznek az írási műveletekkel szemben, mivel az olvasás általában blokkolja az alkalmazást, míg az írás aszinkron módon történik. Annak érdekében, hogy az írási műveletek ne maradjanak teljesen kiszolgálatlanul, az ütemező egy meghatározott számú olvasási művelet után feldolgoz egy köteg késedelmes írási műveletet. Ennek eredménye a következetesen alacsony késleltetés, ami kiválóan alkalmassá teszi adatbázis-kiszolgálókhoz és bármilyen olyan terheléshez, amely olvasási és írási műveleteket kever.

nincs

A none ütemező szinte semmit sem csinál. A kéréseket sorrendben továbbítja az eszközhöz, átrendezés, összevonás vagy prioritás meghatározás nélkül. Ez megfelel a modern NVMe meghajtóknak, amelyek saját belső sorukat kezelik, és egyszerre több tízezer folyamatban lévő kérést tudnak nyomon követni. A szoftveres ütemezési réteg eltávolítása a legrövidebb utat biztosítja az alkalmazás és az eszköz között, ami pontosan az, amire a nagy átviteli sebességű NVMe terheléseknek szükségük van.

A bökkenő az, hogy ez csak akkor működik, ha a hardver önállóan, intelligensen tud ütemezni. A sekély sorral rendelkező HDD-ken vagy SATA SSD-ken a szoftveres átrendezés kihagyása általában rontja a teljesítményt, nem javítja.

BFQ

A BFQ (Budget Fair Queuing) a méltányosságot helyezi előtérbe. Időszeletek helyett minden folyamatnak lemezszektorokban mért keretet biztosít. A nagy szekvenciális olvasási műveletek nagyobb keretet kapnak az átviteli sebesség fenntartása érdekében, míg a késleltetésérzékeny feladatok kisebb keretet kapnak, hogy gyorsan kiszolgálhatók legyenek, és egy visszacsatolási hurok futás közben módosítja a kereteket.

A BFQ nagy terhelés mellett is biztosítja az interaktív feladatok reagálóképességét, így a videolejátszás vagy az adatbázis-lekérdezések zökkenőmentesek maradnak, miközben a háttérben nagy fájlátvitel fut. Ez a méltányosság CPU-erőforrásba kerül. Kérésenkénti overheadje körülbelül 1,9 mikroszekundum, ami körülbelül háromszorosa az mq-deadline-énak, és egy lassabb ARM magon ez az overhead az átviteli sebességet jóval alacsonyabb szintre korlátozza, mint amit ugyanaz a ütemező egy gyors x86 chipen elér. Azokon a szervereken, ahol a nyers átviteli sebesség és a CPU-hatékonyság a legfontosabb, ezt a kompromisszumot nehéz igazolni.

A tervező illesztése a munkaterheléshez

Két dolog határozza meg a megfelelő ütemezőt: a tárolóhardver és az alkalmazás hozzáférési mintája. Kezdjük a hardverrel. Ha az eszköz már átrendezi a kéréseket, mint például egy megfelelő firmware-rel rendelkező NVMe meghajtó, a szoftveres ütemezés csak többletterhelést jelent, így none nyer. A forgó HDD-ken, ahol a keresési idő dominál, a szoftveres átrendezés csökkenti a késleltetést, így mq-deadline vagy bfq a jobb választás. A SATA SSD-k a kettő között helyezkednek el: gyorsabbak a HDD-knél, de nem rendelkeznek az NVMe mély sorával, így mq-deadline illik.

Ugyanez a logika érvényes, ha már valami más végez ütemezést az Ön számára. A virtio-blk-n futó vendég virtuális gépek a gazdagépre támaszkodnak az I/O ütemezésében, a visszaírási gyorsítótárral rendelkező hardveres RAID-vezérlők pedig optimalizálják a saját sorrendjüket. Mindkét esetben none elkerüli a munka kétszeri elvégzését.

A hozzáférési minta a második tényező. Egy adatbázis, amely másodpercenként több ezer véletlenszerű 4K-s olvasást hajt végre, semmi közös nincs egy olyan képzési feladattal, amely nagy szekvenciális blokkokat streamel egy NVMe-tömbből, és ezek különböző ütemezőket igényelnek. Az alábbi táblázat a gyakori munkaterheléseket egy kiindulási ponthoz rendeli.

Van egy kivétel, amit érdemes kiemelni. Még az NVMe-n is, ha a p99 vagy p999-es farok késleltetés az a mutató, ami érdekel, például pénzügyi rendszerekben, mq-deadline akkor none szigorú határidők betartatásával és az alkalmi késleltetett kérések megelőzésével.

A ütemező paramétereinek módosítása és finomhangolása

Mind a kapcsoló ütemezők, mind azok paramétereinek beállítása a sysfs-en keresztül történik, a változtatások teszteléséhez nincs szükség újraindításra.

Az aktív ütemező váltása

Ellenőrizze, mi áll rendelkezésre egy eszköz számára, ahol a zárójelben szereplő érték az aktív:

cat /sys/block/sda/queue/scheduler

Váltson át egy másik ütemezőre futásidőben. Ez azonnal hatályba lép, de az újraindítás után nem marad meg:

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

Ha bfq nem szerepel a listában, először töltse be a modult:

sudo modprobe bfq

Ahhoz, hogy a választás állandó legyen, használjon udev szabályt a régi elevator= kernel paramétert, amely már nem változtatja meg az ütemezőt az RHEL 9 és hasonló kiadásokban. Ez a szabály beállítja a mq-deadline az összes nem rotációs SCSI lemezre a /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"

Töltse be újra és alkalmazza újraindítás nélkül:

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

RHEL-alapú rendszereken a TuneD profilok ugyanazt a feladatot végzik el rendszer-szintű profilok segítségével, az eszközönkénti szabályok helyett.

Beállítani érdemes paraméterek

Minden ütemező a /sys/block/<device>/queue/iosched/alatt. mq-deadlineesetén a határidők jelentik a fő beállítási lehetőségeket. A SATA SSD-ken futó, késleltetésérzékeny adatbázisok számára előnyösebbek a rövidebb határidők:

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

A bfq nagy átviteli sebességű rendszerek esetében a késleltetési heurisztikák letiltása növeli az átviteli sebességet:

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

Megosztott tárhely esetén a BFQ jól illeszkedik a cgroups v2-hez. Az io.weight értékek hozzárendelésével például egy adatbázis-folyamatnak tízszer akkora I/O-részesedést adhat, mint egy biztonsági mentési feladatnak, így a háttérmunkák nem fojthatják el az interaktív forgalmat. Bármit is módosítson, a BFQ magasabb kérésenkénti költsége felhalmozódik a CPU-igényes, magas IOPS-értékű rendszereken, ezért a véglegesítés előtt végezzen teljesítménytesztet.

A teljesítmény ellenőrzése a beállítás után

Mielőtt bármit is megváltoztatna, mindig rögzítse az alapértékeket. Anélkül nem lehet megmondani, hogy a módosítás segített-e.

A fio a szokásos eszköz erre a célra. A blokkméret, a sor mélysége és az I/O-motor beállításai révén reprodukálja a specifikus terhelési mintákat. Mindig adja meg --direct=1 parancsot, hogy megkerülje a lapozási gyorsítótárat, és a gyorsítótárból történő olvasás helyett közvetlenül a ütemezőt és az eszközt mérje. A tesztet igazítsa a valós terheléshez:

Futtassa ugyanazt a tesztet iodepth 1-től 256-ig terjedő értékeken, hogy megtalálja az eszköz telítési pontját, azt a mélységet, ahol az IOPS emelkedése leáll, és a késleltetés megugrik. A változás utáni élő felügyelethez iostat -x 1 jelentse a fontos mutatókat: r_await és w_await az olvasási és írási befejezési késleltetésre, aqu-sz az átlagos sorhosszra, valamint %util az eszköz kihasználtságát. Amikor %util 100 százalék közelében van, a hardver jelenti a korlátot, és semmilyen ütemezőváltoztatás nem segít.

A szoftveres és hardveres költségek elkülönítéséhez futtassa a blktrace parancsot a btt opcióval. Ez felosztja a késleltetést Q2D-re, azaz a szoftveres sorban töltött időre, és D2C-re, azaz az eszköz által a kérés kiszolgálására fordított időre. Ha a Q2D dominál, akkor a ütemező a szűk keresztmetszet. Ha a D2C dominál, akkor a hardver az.

Az eredmények olvasásakor egy dolgot érdemes szem előtt tartani: az ütemező választása leginkább a késleltetés-eloszlás végső értékét határozza meg, nem pedig a mediánt. Átállás none NVMe-re mq-deadline -re az NVMe-n néhány mikroszekundummal megnövelheti a medián késleltetést, miközben a p99 és p999 késleltetést felére csökkenti. Az SLA-khoz kötött, felhasználóknak szóló szolgáltatások esetében ez a kompromisszum szinte mindig megéri, ezért is a gyakorlat lényege a szélső késleltetés mérése, nem pedig az átlagos átviteli sebességé.

A megfelelő ütemező kiválasztása

Az ütemező hangolása arról szól, hogy az algoritmust a hardverhez és az elérési mintához igazítsuk, majd méréssel igazoljuk. Röviden:

• NVMe: használja none és hagyja, hogy a firmware végezze el a sorba állítást.
• SATA SSD-k és HDD-k vegyes I/O-val: használja mq-deadline a kiszámítható késleltetés érdekében.
• Megosztott vagy több felhasználós gazdagépek: használja bfq hogy az egyik munkaterhelés ne fojtsa el a többit.
• A késleltetés alsó határát figyelje, ne a mediánt: az ütemező változásai a p99 és p999 értékekben jelennek meg, ezért ezeket kell mérni.
• Tegye állandóvá: használjon udev szabályokat vagy TuneD-t, soha ne a dead elevator= paramétert.

Bármely ütemező maximális kihasználása olyan hardverrel kezdődik, amely képes lépést tartani. Ha nagy átviteli sebességű, alacsony késleltetésű munkaterhelésekre tervezett, NVMe-alapú szerverekre van szüksége, fedezze fel az FDC VPS-opcióit.