🥇Kerneli seadistamine Linux GlusterFS-i jaoks

Artikli tõlge valmis kursuse alguse eelõhtul Administraator LinuxProfessionaalne».

Aeg-ajalt tekib siin-seal küsimusi Glusteri soovituste kohta tuuma kohandamise kohta ja selle kohta, kas see on vajalik.

See vajadus tekib harva. Enamiku töökoormuste korral töötab tuum väga hästi. Siiski on ka varjukülg. Ajalooliselt on tuum Linux tarbib võimaluse korral meeleldi palju mälu, sealhulgas vahemällu salvestamiseks kui peamiseks viisiks jõudluse parandamiseks.

Enamasti töötab see suurepäraselt, kuid suure koormuse korral võib see probleeme tekitada.

Meil on laialdased kogemused töötamisel palju mälu tarbivate süsteemidega nagu CAD, EDA jms, mis hakkasid suure koormuse korral aeglustuma. Ja mõnikord tekkis meil Glusteris probleeme. Olles jälginud hoolikalt kasutatud mälu ja ketta ooteaega üle ühe päeva, tekkis meil ketta ülekoormus, tohutu iowait, kerneli vead (kernel oops), hanged jne.

See artikkel on paljude erinevates olukordades tehtud parameetrite häälestamise katsete tulemus. Tänu nendele parameetritele ei paranenud mitte ainult reageerimisvõime üldiselt, vaid ka klastri töö oluliselt stabiliseerus.

Mälu konfigureerimisel tasub kõigepealt vaadata virtuaalmälu alamsüsteemi (VM), millel on suur hulk valikuid, mis võivad teid segadusse ajada.

vm.vahetus

Parameeter vm.swappiness määrab, kui palju kernel kasutab vahetust võrreldes RAM-iga. Samuti on see lähtekoodis määratletud kui "kalduvus varastada kaardistatud mälu". Kõrge vahetusväärtus tähendab, et kernel on vastuvõtlikum kaardistatud lehtede vahetamisele. Madal vahetusväärtus tähendab vastupidist: kernel vahetab lehti vähem mälust. Teisisõnu, mida suurem on väärtus vm.swappiness, seda rohkem süsteem vahetust kasutab.

Vahetamise laialdane kasutamine on ebasoovitav, kuna RAM-i laaditakse ja laaditakse maha tohutud andmeplokid. Paljud inimesed väidavad, et vahetusväärtus peaks olema kõrge, kuid minu kogemuse kohaselt annab selle väärtuse „0” seadmine parema jõudluse.

Täpsemalt saad lugeda siit - lwn.net/Articles/100978

Kuid jällegi tuleks neid seadeid kasutada ettevaatlikult ja alles pärast konkreetse rakenduse testimist. Väga koormatud voogedastusrakenduste puhul tuleks selle parameetri väärtuseks määrata "0". Kui muuta väärtuseks "0", paraneb süsteemi reageerimisvõime.

vm.vfs_cache_pressure

See säte juhib mälu, mida kernel kasutab kataloogiobjektide ja inoodide (dentry ja inode) vahemällu salvestamiseks.

Vaikeväärtusega 100 üritab kernel vabastada dentry- ja inode vahemälud õiglasel viisil lehe- ja vahetusvahemällu. Vfs_cache_pressure vähendamine paneb kerneli säilitama dentry ja inode vahemälu. Kui väärtus on "0", ei tühjenda kernel kunagi mälusurve tõttu dentry ja inode vahemälu ning see võib kergesti põhjustada mälutõrke. Kui vfs_cache_rõhk tõuseb üle 100, annab kernel prioriteediks dentry ja inode pageouts.

GlusterFS-i kasutamisel saavad paljud suurte andmemahtude ja paljude väikeste failidega kasutajad inode/dentry vahemällu tõttu hõlpsasti kasutada serveris märkimisväärsel hulgal RAM-i, mis võib viia halva jõudluseni, kuna kernel peab käsitlema süsteemi andmestruktuure. 40 GB mäluga. Selle parameetri määramine suuremaks kui 100 on aidanud paljudel kasutajatel saavutada õiglasemat vahemällu ja kerneli paremat reageerimisvõimet.

vm.dirty_background_ratio ja vm.dirty_ratio

Esimene parameeter (vm.dirty_background_ratio) määrab määrdunud lehtedega mälu protsendi, milleni jõudmisel tuleb alustada määrdunud lehtede taustal kettale loputamist. Kuni selle protsendi saavutamiseni lehti kettale ei loputata. Ja kui lähtestamine algab, töötab see taustal, katkestamata tööprotsesse.

Teine parameeter (vm.dirty_ratio) määrab mälu protsendi, mille määrdunud lehed võivad hõivata enne sundvälgu algust. Kui see lävi on saavutatud, muutuvad kõik protsessid sünkroonseks (blokeeritakse) ja neil ei lubata jätkata töötamist enne, kui nende nõutud sisend-/väljundtoiming on tegelikult lõpule viidud ja andmed on kettal. Suure I/O koormuse korral põhjustab see probleemi, kuna puudub andmete vahemällu salvestamine ja kõik sisend-/väljundprotsessid blokeeritakse I/O ootamisel. Selle tulemuseks on suur hulk rippuvaid protsesse, suur koormus, süsteemi ebastabiilsus ja halb jõudlus.

Nende parameetrite väärtuste vähendamine põhjustab andmete sagedamini kettale loputamist ja neid ei salvestata RAM-i. See võib aidata suure mälumahuga süsteeme, kus on tavaline 45–90 GB lehe vahemälu kettale loputamine, mille tulemuseks on esiotsa rakenduste tohutu latentsusaeg, mis vähendab üldist reageerimisvõimet ja interaktiivsust.

"1" > /proc/sys/vm/pagecache

Lehe vahemälu on vahemälu, mis salvestab andmeid failidest ja käivitatavatest programmidest, st need on lehed, millel on failide või blokeerimisseadmete tegelik sisu. Seda vahemälu kasutatakse ketta lugemiste arvu vähendamiseks. Väärtus "1" tähendab, et vahemälu kasutab 1% RAM-ist ja kettalt loetakse rohkem kui RAM-ist. Seda sätet pole vaja muuta, kuid kui olete lehe vahemälu juhtimise suhtes paranoiline, võite seda kasutada.

"tähtaeg" > /sys/block/sdc/queue/scheduler

I/O ajakava on kerneli komponent. Linux, mis haldab lugemis- ja kirjutamisjärjekordi. Teoreetiliselt on nutika RAID-kontrolleri puhul parem kasutada "noop", sest Linux Planeerija ei tea ketta füüsilise geomeetria kohta midagi, seega on efektiivsem lasta kontrolleril, kellel on ketta geomeetriast head teadmised, päringut võimalikult kiiresti töödelda. Siiski näib "tähtaeg" jõudlust parandavat. Lisateavet planeerijate kohta leiate kerneli lähtekoodi dokumentatsioonist. Linux: linux/Documentation/block/*osched.txt. Ja ma täheldasin ka lugemisvõimsuse suurenemist segaoperatsioonide ajal (palju kirjutamist).

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

I/O päringute arv puhvris enne nende saatmist planeerijale. Mõnede kontrollerite sisemise järjekorra suurus (queue_depth) on suurem kui I/O planeerija nr_requests, seega on I/O planeerijal vähe võimalusi päringuid õigesti prioritiseerida ja liita. Tähtaja ja CFQ planeerijate jaoks on parem, kui nr_requests on 2 korda suurem kui kontrolleri sisemine järjekord. Päringute ühendamine ja ümberjärjestamine aitab planeerijal suure koormuse korral paremini reageerida.

echo "16" > /proc/sys/vm/page-cluster

Leheklastri parameeter juhib lehekülgede arvu, mis korraga vahetusalasse kirjutatakse. Ülaltoodud näites on väärtuseks seatud "16", et see vastaks RAID-riba suurusele 64 KB. Sellel pole mõtet, kui swapiness = 0, kuid kui seate vahetusväärtuseks 10 või 20, aitab selle väärtuse kasutamine teid, kui RAID-riba suurus on 64 KB.

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

Paljude RAID-kontrollerite vaikeblokeerimisseaded põhjustavad sageli kohutavat jõudlust. Ülaltoodud suvandi lisamine konfigureerib ettelugemise 4096*512-baidiste sektorite jaoks. Vähemalt voogedastustoimingute puhul suurendab kiirust kiibil oleva ketta vahemälu täitmine ettelugemise kaudu perioodil, mida kernel sisend-väljundi ettevalmistamiseks kasutab. Vahemälus võib olla andmeid, mida küsitakse järgmise lugemise ajal. Liiga palju ettelugemist võib suurte failide puhul juhusliku sisendi/väljundi hävitada, kui see kasutab potentsiaalselt kasulikku kettaaega või laadib andmeid väljaspool vahemälu.

Allpool on veel mõned soovitused failisüsteemi tasemel. Kuid neid pole veel testitud. Veenduge, et teie failisüsteem teaks triibu suurust ja massiivi ketaste arvu. Näiteks, et see on raid5 massiiv, mille triibu suurus on 64K kuuest kettast (tegelikult viiest, sest ühte ketast kasutatakse paarsuse jaoks). Need soovitused põhinevad teoreetilistele eeldustele ja kogusid RAID-eksperdid erinevatest ajaveebidest/artiklitest.

-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))

Suuremate failide puhul võite kaaluda ülaltoodud triipude suuruse suurendamist.

ETTEVAATUST Kõik ülalkirjeldatud on teatud tüüpi rakenduste puhul äärmiselt subjektiivne. See artikkel ei garanteeri mingeid täiustusi, kui kasutaja pole vastavaid rakendusi eelnevalt testinud. Seda tuleks kasutada ainult siis, kui on vaja parandada süsteemi üldist reageerimisvõimet või kui see lahendab praegused probleemid.