Preklad článku bol pripravený v predstihu pred začiatkom kurzu .
Občas sa objavujú otázky týkajúce sa odporúčaní Gluster ohľadom nastavenia jadra a jeho nevyhnutnosti.
Takáto potreba vzniká zriedka. V drvivej väčšine zaťažení jadro funguje veľmi dobre. Aj keď existuje aj druhá stránka. Historicky, jadro Linuxu ochotne konzumuje veľa pamäte, pokiaľ mu to umožníte, vrátane vyrovnávacej pamäte ako hlavného spôsobu zvyšovania výkonu.
Vo väčšine prípadov to funguje výborne, ale pri silnom zaťažení môže viesť k problémom.
Máme bohaté skúsenosti s systémami, ktoré vyžadovali veľa pamäte, ako sú CAD, EDA a podobné, ktoré sa začali zasekávať pri vysokom zaťažení. Niekedy sme sa stretli s problémami v Gluster. Po starostlivom pozorovaní používania pamäte a času čakania na disky sme zaznamenali ich preťaženie, obrovské iowait, chyby jadra (kernel oops), zaseknutia a pod.
Tento článok je výsledkom mnohých experimentov so nastavovaním parametrov vykonaných v rôznych situáciách. Vďaka týmto parametrom sa nielen zlepšila celková odozva, ale aj významne stabilizovala práca klasteru.
Keď ide o nastavenie pamäte, najprv sa treba pozrieť na podsystem virtuálnej pamäte (VM, virtual memory), ktorý má veľké množstvo možností, schopných vás zmiasť.
vm.swappiness
Parameter vm.swappiness určuje, ako jadro používa swapovanie (swap) v porovnaní s operačnou pamäťou. V zdrojovom kóde je tiež definované ako „tendency to steal mapped memory“ (sklon k krádeži mapovanej pamäte). Vysoká hodnota swappiness znamená, že jadro bude viac naklonené uvoľňovať mapované stránky. Nízka hodnota swappiness znamená opak: jadro bude menej uvoľňovať stránky z pamäte. Inými slovami, čím vyššia je hodnota vm.swappiness, tým viac systém bude používať swap.
Veľké používanie swapovania je neželané, pretože do operačnej pamäte sa nahrávajú a uvoľňujú obrovské bloky dát. Mnohí tvrdia, že hodnota swapiness by mala byť vysoká, ale podľa mojej skúsenosti zvyšuje výkon nastavenie na „0“.
Viac informácií nájdete tu —
Avšak, tieto nastavenia by sa mali používať opatrne a iba po testovaní konkrétnej aplikácie. Pre vysoko zaťažené streamovacie aplikácie by sa táto hodnota mala nastaviť na „0“. Zmenou na „0“ sa zlepšuje odozva systému.
vm.vfs_cache_pressure
Tento parameter riadi pamäť, ktorú jadro spotrebuje na cacheovanie objektov adresárov a indexových deskriptorov (dentry a inode).
Pri predvolenej hodnote 100 sa jadro snaží uvoľniť cache dentry a inode „ferovo“ vo vzťahu ku pagecache a swapcache. Zníženie vfs_cache_pressure znamená, že jadro si uchováva cache dentry a inode. Keď je hodnota rovná „0“, jadro nikdy nevyčistí cache dentry a inode z dôvodu nedostatku pamäte (memory pressure), čo môže ľahko viesť k chybe out-of-memory. Zvýšenie vfs_cache_pressure nad 100 spôsobí, že jadro uprednostňuje uvoľnenie dentry a inode.
Pri používaní GlusterFS môžu viacerí používatelia s veľkými objemami dát a množstvom malých súborov na serveri ľahko využiť značné množstvo operačnej pamäte kvôli cacheovaniu inode/dentry, čo môže viesť k zníženiu výkonu, keďže jadro musí spracovávať štruktúry dát v systéme s 40 GB pamäte. Nastavenie tohto parametra nad 100 pomohlo mnohým používateľom dosiahnuť férovejšie cacheovanie a zlepšiť odozvu jadra.
vm.dirty_background_ratio a vm.dirty_ratio
Prvý parameter (vm.dirty_background_ratio) určuje percento pamäte so špinavými stránkami, dosiahnutie ktorého spúšťa pozadie vyprázdňovania špinavých stránok na disk. Kým tento percentuálny podiel nie je dosiahnutý, stránky nie sú vyprázdnené na disk. A keď sa vyprázdňovanie začne, prebieha na pozadí a nenarušuje bežiace procesy.
Druhý parameter (vm.dirty_ratio) určuje percento pamäte, ktoré môže byť obsadené špinavými stránkami pred začiatkom núteného vyprázdnenia (forced flash). Keď sa dosiahne tento prah, všetky procesy sa stávajú synchronnými (sú zablokované) a nie je im dovolené pokračovať, kým nie je požadovaná operácia vstupu/výstupu skutočne dokončená a údaje nie sú na disku. Pri vysokom zaťažení vstupu/výstupu to spôsobuje problém, pretože chýba vyrovnávacia pamäť, a všetky procesy vykonávajúce vstup/výstup sú zablokované v očakávaní vstupu/výstupu. To vedie k veľkému počtu zmrazených procesov, vysokému zaťaženiu, nestabilnej prevádzke systému a zlému výkonu.
Zníženie hodnôt týchto parametrov vedie k častejšiemu vyprázdneniu údajov na disk a ich neuchovávaniu v RAM. To môže pomôcť systémom s veľkým množstvom pamäte, kde je normálne vyprázdniť na disk vyrovnávaciu pamäť strán s veľkosťou 45–90 GB, čo vedie k obrovským časom čakania pre front-end aplikácie, znižujúc celkovú odozvu a interaktivitu.
«1» > /proc/sys/vm/pagecache
Stránková vyrovnávacia pamäť (page cache) je vyrovnávacia pamäť, v ktorej sú uložené údaje súborov a spustiteľných programov, teda sú to stránky s faktickým obsahom súborov alebo blokových zariadení. Táto vyrovnávacia pamäť sa používa na zníženie počtu čítaní z disku. Hodnota «1» znamená, že pre vyrovnávaciu pamäť sa používa 1% RAM a počet operácií čítania z disku bude vyšší ako z RAM. Zmeniť tento parameter nie je potrebné, ale ak ste paranoidní, pokiaľ ide o kontrolu nad vyrovnávacou pamäťou strán, môžete to využiť.
«deadline» > /sys/block/sdc/queue/scheduler
Plánovač vstupu/výstupu (I/O scheduler) je komponent jadra Linuxu, ktorý spracováva fronty čítania a zápisu. Teoreticky pre inteligentného RAID ovládača je lepšie použiť «noop», pretože Linux nič nevie o fyzickej geometrii disku, takže je efektívnejšie nechať ovládač, ktorý dobre pozná geometriu disku, spracovať požiadavku čo najrýchlejšie. Ale zdá sa, že «deadline» zvyšuje výkon. Viac o plánovačoch sa dá prečítať v dokumentácii k zdrojovému kódu Linuxového jadra: linux/Documentation/block/*osched.txt. A tiež som zaznamenal zvýšenie priepustnosti pri čítaní počas zmiešaných operácií (veľa zápisových operácií).
«256» > /sys/block/sdc/queue/nr_requests
Počet vstupno-výstupných požiadaviek v bufferi pred ich odoslaním plánovaču. Veľkosť vnútorného radu niektorých ovládačov (queue_depth) je väčšia ako nr_requests plánovača vstupov-výstupov, takže plánovač má málo šancí správne priorizovať a vykonávať zlúčenie požiadaviek. Pre plánovače deadline a CFQ je lepšie, keď je nr_requests dvakrát väčšie než vnútorný rad ovládača. Zlúčenie a preusporiadanie požiadaviek pomáha plánovaču byť pružnejším pri veľkej záťaži.
echo «16» > /proc/sys/vm/page-cluster
Parametr page-cluster riadi počet strán, ktoré sa zapíšu do swapu naraz. V uvedenom príklade je hodnota nastavená na '16' podľa veľkosti stripe (stripe size) RAID s 64 KB. To nedáva zmysel pri swappiness = 0, ale ak ste nastavili swappiness na 10 alebo 20, použitím tejto hodnoty vám to pomôže, keď je veľkosť stripe RAID 64 KB.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc alebo dev_mapper)
Predvolené nastavenia blokových zariadení pre mnoho RAID ovládačov často vedú k hroznej výkonnosti. Pridanie vyššie uvedenej možnosti nastavuje predbežné čítanie pre 4096 * 512-bytové sektory. Aspoň pre streamové operácie sa zvyšuje rýchlosť, naplnením vstavaného cache disku prebiehajúcim predbežným čítaním počas obdobia, ktoré jadro používa na prípravu vstupov-výstupov. Do cache môžu byť umiestnené dáta, ktoré budú požadované pri nasledujúcom čítaní. Príliš veľké predbežné čítanie môže zabiť náhodný vstup-výstup pre veľké súbory, ak využíva potenciálne užitočný čas disku alebo načítava dáta mimo cache.
Nižšie sú niektoré ďalšie odporúčania na úrovni súborového systému. Avšak ešte neboli testované. Uistite sa, že váš súborový systém pozná veľkosť stripe a počet diskov v poli. Napríklad, že ide o RAID 5 pole s veľkosťou stripe 64K z piatich diskov (v skutočnosti z piatich, pretože jeden disk sa používa na paritu). Tieto odporúčania sú založené na teoretických predpokladoch a sú zozbierané z rôznych blogov/statistík expertov na RAID.
-> ext4 fs, 5 diskov, 64K stripe, jednotky v 4K blokoch
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 diskov, 64K stripe, jednotky v 512-bytových sektoroch
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))Pre zvýšené súbory môžete zvážiť možnosť zvýšenia uvedených rozmerov stripe.
POZOR! Všetko, čo bolo uvedené vyššie, je veľmi subjektívne pre niektoré typy aplikácií. Tento článok nezaručuje žiadne vylepšenia bez predchádzajúceho testovania príslušných aplikácií používateľom. Mal by sa aplikovať iba v prípade potreby zlepšiť celkovú odozvu systému alebo ak rieši aktuálne problémy.
Ďalšie materiály:
Čítať viac
Zdroj: habr.com
