🥇Linuxi tuuma seadistamine GlusterFS-ile

Artikli tõlge on ettevalmistatud kursuse alguseks «Administrator Linux. Professional».

Kaasas on aeg-ajalt küsimusi Glustermi tuumaseadistuse soovituste kohta ja kas see on vajalik.

Tegelik vajadus tekib harva. Enamikul koormustel töötab tuum väga hästi. Kuigi on ka teiselt poolt. Ajalooliselt tarbib Linuxi tuum meelsasti suures koguses mälu, kui tal seda võimaldatakse, sealhulgas mälukaotuse kaudu, mis on peamine viis jõudluse suurendamiseks.

Enamikel juhtudel töötab see suurepäraselt, kuid suurte koormuste korral võib see põhjustada probleeme.

Meil on suur kogemus mälutarbimist vajavate süsteemide, nagu CAD, EDA ja sarnaste, töötlemisel, mis hakkasid suure koormuse korral aeglustuma. Ja mõnikord oleme kokku puutunud probleemidega Glusteris. Pärast mitme päeva jooksul jälgimist kasutatud mälu ja kettaseisakute aegade osas saime nende koormuse, tohutu iowaiti, tuuma vead (kernel oops), hangumised jne.

See artikkel on paljude katsete tulemus, kus on seadistatud parameetreid erinevates olukordades. Nende parameetrite abil on paranenud mitte ainult üldine reageerimisvõime, vaid ka klaster on märgatavalt stabiilsem.

Kui räägitakse mälu seadistamisest, tuleb esmalt vaadata virtuaalse mälusüsteemi (VM, virtual memory) poole, millel on palju valikuid, mis võivad teid segadusse ajada.

vm.swappiness

Parameeter vm.swappiness määrab, kui palju tuum kasutab vahetust (swap, podkatk) võrreldes operatiivmälu kasutamisega. Algkoodis on see samuti defineeritud kui «tendency to steal mapped memory» (kaldumine varastada kaardistatud mälu). Kõrge swappiness'i väärtus tähendab, et tuum on tõenäolisem, et vabastab kaardistatud leheküljed. Madal swappiness'i väärtus tähendab vastupidist: tuum vabastab vähem lehekülgi mälust. Teisisõnu, mida kõrgem on väärtus vm.swappiness, seda enam süsteem kasutab vahetusmälu.

Suur swap'i kasutamine pole soovitatav, kuna mällu laaditakse ja sealt eemaldatakse suuri andmepakette. Paljud väidavad, et swapnessi väärtus peaks olema kõrge, kuid minu kogemuse kohaselt parandab jõudlust selle seadmine '0'-le.

Lisainfot leiate siit — lwn.net/Articles/100978

Kuid need seaded tuleb siiski rakendada ettevaatlikult ja ainult pärast konkreetse rakenduse testimist. Kõrge koormusega voogedastusrakenduste puhul tuleks see seade seadistada '0'-le. Seadmisega '0' paraneb süsteemi reageerimisvõime.

vm.vfs_cache_pressure

See parameeter reguleerib mälukasutust, mida tuum kasutab katalooge ja indeksit väärtusi (dentry ja inode) vahemällu salvestamiseks.

Vaikese seade väärtus 100, tuum püüab "õiglaselt" vabastada dentry ja inode vahemälu pagecache ja swapcache suhtes. vfs_cache_pressure'i vähendamine viib selleni, et tuum hoiab dentry ja inode vahemälud. Kui väärtus on "0", ei puhasta tuum kunagi dentry ja inode vahemälu mälu survetõusu tõttu, mis võib kergesti viia out-of-memory veani. vfs_cache_pressure'i suurendamine üle 100 annab tuumale eelise dentry ja inode laadimise vabastamisel.

GlusterFS-i kasutamisel võivad paljud kasutajad koos suurte andmehulkade ja paljude väikeste failidega hõivata serveris märkimisväärse hulga mälu inode/dentry vahemälu tõttu, mis võib põhjustada jõudluse langust, kuna tuumal on 40 GB mälu süsteemis andmestruktuuride töötlemine. Selle parameetri seadmine üle 100 on aidanud paljusid kasutajaid saavutada õiglasemat vahemälu haldamist ja parandada tuuma reageerimisvõimet.

vm.dirty_background_ratio ja vm.dirty_ratio

Esimene parameeter (vm.dirty_background_ratio) määrab protsendi mälust, millel on mustad leheküljed, saavutades mis tahes protsendi, mille korral tuleb alustada mustade lehekülgede taustal väljastamist kettale. Seni, kuni seda protsenti ei saavutata, ei kirjutata lehekülgi kettale. Ja kui väljastamine algab, toimub see taustal, katkestamata aktiivseid protsesse.

Teine parameeter (vm.dirty_ratio) määrab protsendi mälust, mis võib olla hõivatud mustade lehekülgedega enne sundväljastamise (forced flash) algust. Kui see künnis on saavutatud, muutuvad kõik protsessid sünkroonseks (bloqeeritakse) ning neil ei lubata jätkata tööd, kuni nende taotletud sisendi/väljundi operatsioon ei ole tegelikult lõpule viidud ja andmed ei ole kettale salvestatud. kõrge koormuse korral põhjustab see probleeme, kuna andmete vahemälu puudub ja kõik sisendi/väljundi teostavad protsessid on blokeeritud ootamas sisendi/väljundi teostamist. See põhjustab suurt hulka seiskunud protsesse, kõrget koormust, süsteemi ebastabiilsust ja kehva jõudlust.

Nende parameetrite väärtuste vähendamine toob kaasa andmete sagedasema kirjutamise kettale ja mitte mällu salvestamise. See võib aidata süsteemides, kus on suur mälumaht, kus on normaalne 45–90 GB suuruste lehekettide vahemälu kettale kirjutamine, mis suurendab ooteaega esifassaadirakendustes, vähendades üldist reageerimiskiirust ja interaktiivsust.

«1» > /proc/sys/vm/pagecache

Lehekett (page cache) on vahemälu, kus hoitakse failide ja käivitatavate programmide andmeid, st need on lehed, millel on tegelikud failide või plokkseadmete sisu. Seda vahemälu kasutatakse kettalt lugemise vähendamiseks. Väärtus «1» tähendab, et vahemälus kasutatakse 1% mälust ja kettalt lugemise operatsioone on rohkem kui mälust. Selle parameetri muutmine ei ole vajalik, kuid kui olete lehekettide ülevaate kontrollimisel paranoiline, siis võite selle kasutada.

«deadline» > /sys/block/sdc/queue/scheduler

Sisend-väljundi planeerija (I/O scheduler) on Linuxi tuuma komponent, mis töötleb lugemise ja kirjutamise järjekordi. Teoreetiliselt on nutika RAID-kontrolleri jaoks parem kasutada 'noop'-i, kuna Linux ei tea midagi ketta füüsilisest geomeetriast. Seega on efektiivsem lasta kontrolleril, kes tunneb ketta geomeetriat, võimalikult kiiresti päringud töödelda. Kuid tundub, et 'deadline' parendab tootlikkust. Rohkem planeerijate kohta saab lugeda Linuxi tuuma lähtekoodi dokumentatsioonist: linux/Documentation/block/*osched.txt. Samuti olen märganud lugemise läbilaskvuse suurendamist segatud operatsioonide korral (palju kirjutamisoperatsioone).

'256' > /sys/block/sdc/queue/nr_requests

Puutegurite arv, mis on puhverdatud enne, kui need edastatakse ajakavasse. Mõnede kontrollerite sisejärjekorra (queue_depth) suurus on suurem kui nr_requests sisse-/väljundikava, mistõttu on sisend-väljundikavas vähe võimalusi õigesti prioriseerida ja täita päringute ühendamine. Deadline ja CFQ ajakavade puhul on parem, kui nr_requests on kaks korda suurem kui kontrolleri sisejärjekord. Päringute ühendamine ja ümberkorraldamine aitab ajakavale olla suure koormuse korral tundlikum.

echo «16» > /proc/sys/vm/page-cluster

Parameeter page-cluster haldab lehtede arvu, mis kirjutatakse korraga vahetusse. Ülaltoodud näites on väärtus seadistatud «16», vastavalt RAID-i striibi (stripe size) suurusele 64 KB. See ei oma tähendust, kui swappiness = 0, kuid kui olete seadnud swappiness väärtuseks 10 või 20, siis aitab selle väärtuse kasutamine, kui RAID-i striibi suurus on 64 KB.

blockdev --setra 4096 /dev/`<`devname`>` (-sdb, hdc või dev_mapper)

Paljuski RAID kontrollerite vaikeseaded toovad sageli kaasa halva jõudluse. Ülaltoodud valiku lisamine seadistab eelaimingu 4096 * 512-baidi sektoritele. See suurendab vähemalt voogedastuse operatsioonide kiirus, täites ketta sisseehitatud vahemälu eelaimimisega, samal ajal kui tuuma aeg kasutatakse sisend-väljundiks valmistamiseks. Vahemällu saab salvestada andmed, mis järgmisel lugemisel taaskasutatakse. Liigne eelaiming võib halvendada juhuslikku sisend-väljundit suurte failide korral, kui see kasutab potentsiaalselt kasulikku kettategevuse aega või laadib andmeid vahemälust välja.

Allpool on mõned lisasoovitused failisüsteemi tasemel. Kuid neid ei ole veel testitud. Veenduge, et teie failisüsteem teab striibi suurust ja ketaste arvu massiivis. Näiteks, et see on raid5 massiiv, mille striibi suurus on 64K ja kuus ketast (tegelikult viit, kuna üks ketas on pariteedi jaoks). Need soovitused põhinevad teoreetilistel eeldustel ja on kogutud erinevatest blogidest/RAIDi ekspertide artiklitest.

-> ext4 fs, 5 ketast, 64K striip, ühikutes 4K plokkides
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 ketast, 64K striip, ühikutes 512-byte sektorites
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))

Suuremate failide puhul võib kaaluda eeltoodud striibide suuruste suurendamist.

TÄHELEPANU! Kõik, mis on ülaltoodud, on mõne tüüpi rakenduste jaoks äärmiselt subjektiivne. See artikkel ei garanteeri mingeid parandusi ilma vastava rakenduse eelneva testimiseta kasutaja poolt. Seda tuleks rakendada ainult juhtudel, kui on vajalik süsteemi üldise reageerimise parandamine või kui see lahendab praeguseid probleeme.