🥇Linuxi kernel GlusterFS-i jaoks

Artikli tõlge on koostatud kursuse alguse eelõhtul «Linuxi administraator. Professionaalne».

Aeg-ajalt tekivad küsimused Glusteri soovituste osas tuuma seadistamiseks ja kas see on vajalik.

Selline vajadus tekib harva. Enamikul koormustel töötab tuum väga hästi. Kuigi on ka teine külg. Ajalooliselt tarbib Linuxi tuum meelsasti palju mälu, kui talle selline võimalus anda, sealhulgas vahemälu kasutamise puhul peamise jõudluse tõstmise viisi.

Enamikul juhtudel töötab see suurepäraselt, kuid suure koormuse korral võib see põhjustada probleeme.

Meil on suur kogemus mälu intensiivselt kasutavate süsteemide, nagu CAD, EDA jne, osas, millel on olnud aeglane töö kõrge koormuse korral. Ja mõnikord oleme Glusteri osas probleemidega silmitsi seisnud. Pärast mitme päeva jälgimist mälu ja kettade ooteaegade osas saime nende ülekoormuse, tohutud iowait'id, tuuma vead (kernel oops), hangumised jne.

See artikkel on paljude eksperimentide tulemus parameetrite seadistamiseks erinevates olukordades. Tänu nendele parameetritele mitte ainult, et üldine reageerimine paranes, vaid ka klaster stabiliseerus oluliselt.

Kui asi puudutab mälu seadistamist, siis tuleb esmakordselt vaadata virtuaalmälu ala (VM, virtual memory), millel on palju võimalusi, mis võivad teid segadusse ajada.

vm.swappiness

Parameeter vm.swappiness määrab, kuivõrd tuum kasutab swapimist võrreldes ülesmälu. Algkoodis määratletakse see ka kui «tendency to steal mapped memory» (kalduvus varastada kaardistatud mälu). Kõrge swappiness'i väärtus tähendab, et tuum on kalduvam kaardistatud lehti välja viskama. Madal swappiness'i väärtus tähendab vastupidist: tuum viskab lehti vähem välja. Teisisõnu, mida kõrgem on väärtus vm.swappiness, seda rohkem süsteem kasutab swap'i.

Suure swapimise kasutamine ei ole soovitatav, kuna operatiivmälu laadib sisse ja välja tohutuid andmeplokke. Paljud väidavad, et swapiness'i väärtus peab olema kõrge, kuid minu kogemuse kohaselt viib jõudluse suurendamine selle seadistamisega «0».

Rohkem saab lugeda siit — lwn.net/Articles/100978

Kuid jällegi, neid seadistusi tuleb rakendada ettevaatlikult ja ainult pärast konkreetse rakenduse testimist. Suure koormusega voogedastusrakenduste puhul tuleks see väärtus seada „0” peale. Muutmine „0” peale parandab süsteemi reageerimisvõimet.

vm.vfs_cache_pressure

See parameeter kontrollib mälu, mida tuum kasutab katalooge ja indeksideskirju (dentry ja inode) seadistamiseks.

Algselt väärtusel 100 proovib tuum vabastada dentry ja inode vahemälu „õigluse” alusel võrreldes pagecache ja swapcache'ga. vfs_cache_pressure'i vähendamine põhjustab, et tuum hoiab dentry ja inode vahemälusid. Kui väärtus on „0”, ei eemalda tuum kunagi dentry ja inode vahemälu mälu puuduse (memory pressure) tõttu, mis võib kergesti põhjustada mälupuuduse viga. vfs_cache_pressure'i suurendamine üle 100 seab dentry ja inode väljalaskmise prioriteediks.

GlusterFS-i kasutamisel võivad paljusid suuri andmehulkadega kasutajaid ja väikeste failide arvu tõttu serveris oluliselt kasutada läbi inode/dentry vahemälu märkimisväärne hulk RAM-i, mis võib viia jõudluse vähenemiseni, kuna tuum peab töötlema andmestruktuure süsteemis, kus on 40 GB mälu. Selle parameetri seadmine üle 100 aitas paljudel kasutajatel saavutada õiglasemat vahemälu haldust ja parandada tuuma reageerimisvõimet.

vm.dirty_background_ratio ja vm.dirty_ratio

Esimene parameeter (vm.dirty_background_ratio) määrab protsendi mälust, kus on määrdunud lehed, saavutades, mil peab alustama määrdunud lehtede foonset salvestamist kettale. Seni, kuni seda protsenti ei saavutata, ei salvestata lehti kettale. Ja kui salvestamine algab, toimub see foonrežiimis, katkestamata töötavaid protsesse.

Teine parameeter (vm.dirty_ratio) määrab protsendi mälust, mida võivad hõivata määrdunud lehed enne sundvälistamist (forced flash). Kui see lävi saavutatakse, muutuvad kõik protsessid sünkroonseks (blokeeruvad) ja neil ei lubata jätkata, kuni nende küsitud sisend-väljundoperatsioon on tegelikult lõpetatud ja andmed on kettal. Suurte sisend-väljundide koormuse korral tekib probleem, kuna andmete vahemälu puudub ja kõik sisend-väljundit teostavad protsessid blokeeruvad ootama sisend-väljundit. See toob kaasa palju tõkestatud protsesse, kõrge koormuse, ebastabiilse süsteemi töö ja kehva jõudluse.

Nende parameetrite väärtuste vähendamine toob kaasa selle, et andmed kirjutatakse sagedamini kettale ja ei jää OŽU-sse. See võib aidata süsteemidel, millel on suur hulk mälu, mille jaoks on normaalne kirjutada kettale 45–90 GB suuruse lehekülje vahemälu, mis toob kaasa tohutu ooteaja frontend- rakendustele, vähendades üldist reageerimisvõimet ja interaktiivsust.

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

Lehekülje vahemälu (page cache) on vahemälu, kuhu salvestatakse failide ja käivitatavate programmide andmeid, see tähendab, et need on lehed, millel on tegelike failide või plokkseadmete sisu. Selle vahemälu eesmärk on vähendada kettalt lugemise arvu. Väärtus «1» tähendab, et vahemälu kasutab 1% OŽU-st ja kettalt lugemise operatsioone on rohkem kui OŽU-st. Selle parameetri muutmine ei ole vajalik, kuid kui olete lehekülgede vahemälu üle äärmiselt tähelepanelik, võite seda kasutada.

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

Sisend-väljundi planeerija (I/O scheduler) on Linuxi tuuma komponent, mis haldab lugemis- ja kirjutamisjärjekordi. Teoreetiliselt on nutika RAID-kontrolleri jaoks parem kasutada «noop», kuna Linux ei tea ketta füüsilisest geomeetriast midagi, seega on tõhusam lasta kontrolleril, kes teab geomeetriat, töödelda päringud võimalikult kiiresti. Kuid tundub, et «deadline» suurendab jõudlust. Roykide planeerijate kohta saab rohkem lugeda Linuxi tuuma allika dokumendist: linux/Documentation/block/*osched.txt. Ja olen samuti täheldanud lugemise läbilaskevõime suurenemist segatud operatsioonide (palju kirjutamisoperatsioone) ajal.

«256» > /sys/block/sdc/queue/nr_requests

Sisend-väljundiga küsimuste arv puhvrisse enne, kui need edastatakse planeerijale. Teatud kontrollerite sisemiste järjekordade (queue_depth) suurus on suurem kui planeerija sisend-väljundiküsimuste nr_requests, mis tähendab, et planeerijal on vähe võimalusi küsimuste õigesti prioriseerida ja liita. Deadline ja CFQ planeerijate puhul on parem, kui nr_requests on kaks korda suurem kui kontrolleri sisemine järjekord. Küsimuste ühendamine ja ümberjärjestamine aitab planeerijal suure koormuse korral olla reageerivam.

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

Parameeter page-cluster reguleerib lehekülgede arvu, mis kirjutatakse swap'i korraga. Ülaltoodud näites määratakse väärtus «16» vastavalt RAID-i ribasuurusele (stripe size) 64 KB. See pole mõistlik, kui swappiness = 0, kuid kui olete seadnud swappinessi väärtuseks 10 või 20, siis aitab selle väärtuse kasutamine, kui RAID-i ribasuurus on 64 KB.

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

Paljude RAID-kontrollerite vaikeseaded võivad põhjustada kohutavat jõudlust. Ülaltoodud valiku lisamine seadistab ennetava lugemise 4096 * 512-baytiste sektorite jaoks. Vähemalt voogesituse puhul suureneb kiirus, täites seadme sisseehitatud vahemälu ennetava lugemise ajal, kui tuuma ettevalmistamiseks kulub aega. Vahemälusse võivad paigutuda andmed, mida küsitakse järgmise lugemise ajal. Liigne ennetav lugemine võib hävitada juhusliku sisend-väljundi suuremate failide jaoks, kui see kasutab potentsiaalselt kasulikku ketta aega või laeb andmeid vahemälust väljapoole.

Siin on veel mõned süsteemifaili taseme soovitused. Kuid neid pole veel testitud. Veenduge, et teie failisüsteem teab ribasuurust ja ketaste arvu massiivis. Näiteks, et see on RAID5 massiiv ribasuurusega 64K kuue ketta peal (tegelikult viie, kuna üks ketas on kasutusel pariteedi jaoks). Need soovitused põhinevad teoreetilistel oletustel ja on kogutud erinevatest RAID-ekspertide blogidest/-artiklitest.

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

Suuremate failide jaoks võib kaaluda ülaltoodud ribade suuruste suurendamist.

TÄHELEPANU! Kõik, mis on eespool kirjeldatud, on mõnede rakendustüüpide jaoks äärmiselt subjektiivne. See artikkel ei garanteeri mingite parenduste saavutamist ilma vastavate rakenduste eeltestimiseta kasutaja poolt. Seda tuleks rakendada ainult siis, kui on vajalik süsteemi üldise reageerimisvõime parandamine või kui see lahendab olemasolevaid probleeme.