Linuxi I/O-ajastaja häälestamine: mq-deadline, none ja BFQ

Linuxi I/O-ajastaja otsustab, millises järjekorras jõuavad lugemis- ja kirjutamisnõuded teie salvestusseadmeni, ning õige valik sõltub peaaegu täielikult teie riistvarast. Kasutage none NVMe jaoks, mq-deadline SATA SSD-de ja HDD-de puhul, mis töötavad segatud töökoormustega, ning bfq kui on vaja takistada ühel protsessil teisi protsesse nälga jätmast. Käesolev juhend käsitleb kolme peamise ajastaja tööpõhimõtet, nende sobitamist teie töökoormusega ning tulemuse häälestamist ja kontrollimist.

Kui soovite enne lugemist praktilist ülevaadet, siis see video tutvustab ajastite vahetamise ja testimise põhitõdesid terminalis.

Kuidas erinevad mq-deadline, none ja BFQ

Iga ajastaja töötleb päringuid erineva strateegiaga. Nende erinevuste tundmine võimaldab teil teha teadliku valiku, selle asemel et kasutada seda, mille tuum valis käivitamisel.

mq-deadline

mq-deadline mq-deadline ajastaja tagab, et ükski päring ei oota lõputult. See hoiab lugemiseks ja kirjutamiseks eraldi sorteeritud järjekordi, järjestades need loogilise ploki aadressi järgi, et vähendada otsimisaega, ning kehtestab tähtajad: vaikimisi 500 ms lugemiseks ja 5 sekundit kirjutamiseks. Kui päring jõuab oma tähtajani, hüppab see järjekorra etteotsa.

Lugemine on kirjutamisest prioriteetsem, kuna lugemine blokeerib tavaliselt rakendust, samas kui kirjutamine toimub asünkroonselt. Et kirjutamine ei jääks täielikult kõrvale, teenindab ajastaja pärast kindlat arvu lugemisi kogumi tähtaja ületanud kirjutamisi. Tulemuseks on järjepidevalt madal latentsus, mis teeb selle sobivaks andmebaasiserveritele ja igasugusele töökoormusele, kus segunevad lugemine ja kirjutamine.

puudub

Ajastaja none ajastaja ei tee peaaegu midagi. Ta edastab päringud otse seadmele First-In-First-Out-järjekorras, ilma ümberjärjestamise, ühendamise või prioriteetide seadmiseta. See sobib kaasaegsetele NVMe-kettadele, mis haldavad oma sisemisi järjekordi ja suudavad jälgida kümneid tuhandeid käimasolevaid päringuid korraga. Tarkvara ajastamiskihi eemaldamine annab võimalikult lühima tee rakendusest seadmeni, mis on täpselt see, mida suure läbilaskevõimega NVMe-töökoormused vajavad.

Kuid see toimib ainult siis, kui riistvara suudab ise intelligentselt ajastada. HDD-del või SATA SSD-del, millel on lühikesed järjekorrad, halvendab tarkvara ümberjärjestamise väljajätmine tavaliselt jõudlust, mitte ei paranda seda.

BFQ

BFQ (Budget Fair Queuing) seab esikohale õigluse. Ajalõikude asemel annab see igale protsessile eelarve, mida mõõdetakse kettasektorites. Suured järjestikused lugejad saavad suurema eelarve, et läbilaskevõime püsiks kõrgel, samas kui latentsusele tundlikud ülesanded saavad väiksema eelarve, et neid teenindataks kiiresti, ning tagasisideahel kohandab eelarveid töötamise käigus.

BFQ hoiab interaktiivsed ülesanded reageerimisvõimelisena isegi suure koormuse all, nii et videote taasesitus või andmebaasi päringud jäävad sujuvaks, samal ajal kui taustal toimub suurte failide edastamine. See õiglus maksab CPU-le. Selle ühe päringu koormus on umbes 1,9 mikrosekundit, mis on umbes kolm korda suurem kui mq-deadline'il, ning aeglasemal ARM-tuumal piirab see koormus läbilaskevõimet tunduvalt alla selle, mida sama ajastaja saavutab kiirel x86-kiibil. Serverites, kus toores läbilaskevõime ja CPU tõhusus on kõige olulisemad, on seda kompromissi raske õigustada.

Scheduler'i sobitamine teie töökoormusega

Õige ajastaja valimisel on otsustavaks kaks asja: teie salvestusseadmed ja teie rakenduse juurdepääsumuster. Alustage riistvarast. Kui seade juba järjestab päringuid ümber, nagu näiteks võimeka püsivara ja tarkvaraga NVMe-kõvaketas, lisab tarkvaraline ajastamine ainult lisakoormust, seega none võidab. Pöörlevatel kõvaketastel, kus otsimisaeg domineerib, vähendab tarkvara ümberjärjestamine latentsust, seega mq-deadline või bfq on paremad valikud. SATA SSD-d asuvad vahepeal: kiiremad kui HDD-d, kuid ilma NVMe sügavate järjekordadeta, mis on koht, kus mq-deadline sobib.

Sama loogika kehtib ka siis, kui midagi muud juba teie eest ajastab. Virtio-blk-l töötavad külalis-VM-id tuginevad I/O ajastamisel peremehele ning riistvaralised RAID-kontrollerid kirjutuspuhvriga optimeerivad oma järjekorda ise. Mõlemal juhul none vältitakse töö eest kahekordset maksmist.

Juurdepääsumuster on teine tegur. Andmebaasil, mis teeb tuhandeid juhuslikke 4K-lugemisi sekundis, pole midagi ühist õppimisülesandega, mis voogedastab suuri järjestikuseid plokke NVMe-massiivilt, ning need vajavad erinevaid ajastajaid. Allolev tabel seostab tavalised töökoormused lähtepunktiga.

On üks erand, mida tasub esile tõsta. Isegi NVMe puhul, kui teile on oluline p99 või p999 viivitus, näiteks finantssüsteemides, mq-deadline võib none rangete tähtaegade kehtestamisega ja aeg-ajalt esinevate viivitatud päringute vältimisega.

Scheduler'i parameetrite muutmine ja häälestamine

Nii ajastite vahetamine kui ka nende parameetrite häälestamine toimub sysfs-i kaudu, muutuste testimiseks ei ole vaja süsteemi taaskäivitada.

Aktiivse ajastaja vahetamine

Kontrollige, mis on seadme jaoks saadaval, kus sulgudes olev väärtus on aktiivne:

cat /sys/block/sda/queue/scheduler

Vahetage töötamise ajal teise ajastusseadistuse vastu. See hakkab kehtima kohe, kuid ei säili taaskäivitamisel:

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

Kui bfq ei ole loetelus, laadige esmalt moodul:

sudo modprobe bfq

Et valik püsiks, kasutage udev-reeglit, mitte vana elevator= tuumaparameetri asemel, mis RHEL 9 ja sarnastes versioonides ajastajat enam ei muuda. See reegel seab mq-deadline kõikidele mitte-rotatsioonilistele SCSI-ketastele /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"

Laadige see uuesti ja rakendage ilma taaskäivitamiseta:

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

RHEL-põhistes süsteemides teevad TuneD-profiilid sama tööd süsteemiüleste profiilide kaudu, mitte seadmespetsiifiliste reeglite abil.

Reguleerimist väärivad parameetrid

Iga ajastaja avaldab oma reguleeritavad parameetrid kataloogis /sys/block/<device>/queue/iosched/. mq-deadline, on tähtajad peamised hoovad. SATA SSD-del asuvad latentsusele tundlikud andmebaasid saavad kasu lühemate tähtaegade kasutamisest:

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

Suure läbilaskevõimega süsteemide puhul bfq suure läbilaskevõimega süsteemide puhul suurendab latentsuse heuristika keelamine läbilaskevõimet:

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

Jagatud hostingus sobib BFQ hästi kokku cgroups v2-ga. io.weight võimaldab teil anda andmebaasiprotsessile näiteks kümme korda suurema I/O-osa kui varundustööle, nii et taustatöö ei suuda interaktiivset liiklust üle trumbata. Mis tahes muudatusi te ka ei teeks, BFQ kõrgemad kulud päringu kohta kumuleeruvad CPU-piiranguga, kõrge IOPS-iga süsteemides, seega tehke enne rakendamist võrdlustest.

Jõudluse kontrollimine pärast häälestamist

Enne mis tahes muudatuste tegemist tuleb alati salvestada baasjoon. Ilma selleta pole võimalik öelda, kas muudatus aitas.

fio on selleks standardne tööriist. See taastab spetsiifilised koormusmustrid ploki suuruse, järjekorra sügavuse ja I/O-mootori seadete kaudu. Kasutage alati --direct=1 , et see möödaks lehekülje vahemälust ja mõõdaks otse ajastajat ja seadet, mitte vahemällu salvestatud lugemisi. Kohandage test tegeliku töökoormusega:

Käivita sama test iodepth väärtustega 1 kuni 256, et leida seadme küllastumispunkt, sügavus, kus IOPS-i kasv peatub ja latentsus tõuseb järsult. Muudatusejärgseks reaalajas jälgimiseks iostat -x 1 esitab olulised näitajad: r_await ning w_await lugemise ja kirjutamise lõpetamise latentsuse kohta, aqu-sz keskmise järjekorra pikkuse kohta ning %util seadme kasutamise kohta. Kui %util on ligi 100 protsenti, on piiriks riistvara ja ükski ajastaja muudatus ei aita.

Tarkvara- ja riistvarakulude eristamiseks käivitage blktrace koos btt-ga. See jagab latentsuse Q2D-ks, mis on tarkvara järjekorras veedetud aeg, ja D2C-ks, mis on aeg, mida seadmel kulub päringu teenindamiseks. Kui Q2D domineerib, on ajastaja teie pudelikaelaks. Kui D2C domineerib, on selleks riistvara.

Tulemuste lugemisel tuleb meeles pidada üht asja: ajastaja valik mõjutab peamiselt latentsuse jaotuse saba, mitte mediaani. Üleminek none NVMe-le mq-deadline NVMe-l võib tõsta mediaanlatentsust mõne mikrosekundi võrra, samas kui p99 ja p999 latentsust vähendatakse poole võrra. SLA-dega seotud kasutajale suunatud teenuste puhul on see kompromiss peaaegu alati seda väärt, mistõttu ongi selle harjutuse mõte mõõta latentsuse saba, mitte keskmist läbilaskevõimet.

Õige ajastaja valimine

Planeerija häälestamine tähendab algoritmi kohandamist riistvarale ja juurdepääsumustrile ning selle tõendamist mõõtmistega. Lühidalt:

• NVMe: kasuta none ja laske püsivara järjekorda panna.
• SATA SSD-d ja HDD-d segatud I/O-ga: kasuta mq-deadline , et tagada etteaimatav latentsus.
• Jagatud või mitme kasutajaga hostid: kasuta bfq , et üks töökoormus ei võtaks teistelt ressursse ära.
• Jälgige latentsuse saba, mitte mediaani: ajastaja muudatused ilmnevad p99 ja p999 juures, seega just seda tuleb mõõta.
• Tee see püsivaks: kasuta udev-reegleid või TuneD-d, mitte kunagi dead elevator= parameetrit.

Iga ajastaja maksimaalse potentsiaali ärakasutamine algab riistvarast, mis suudab sammu pidada. Kui vajate NVMe-põhiseid servereid, mis on loodud suure läbilaskevõimega ja madala latentsusega töökoormuste jaoks, uurige FDC VPS-i võimalusi.