🥇Postavke Linux jezgre za GlusterFS

Prijevod članka pripremljen je uoči početka tečaja «Administrator Linux. Profesionalac».

Povremeno se postavljaju pitanja o preporukama Gluster-a u vezi s podešavanjem jezgre i postoji li za to potreba.

Takva potreba se rijetko javlja. Na većini opterećenja jezgra dobro radi. Ipak, postoji i druga strana. Povijesno gledano, Linux jezgra sklona je konzumiranju velike količine memorije ako joj se to dopusti, uključujući i korištenje za keširanje kao primarni način poboljšanja performansi.

U većini slučajeva to funkcionira izvrsno, ali kod velikih opterećenja to može dovesti do problema.

Imamo veliko iskustvo s sustavima koji troše mnogo memorije, poput CAD, EDA i sličnih, koji su počeli usporavati pri visokim opterećenjima. Ponekad smo se susretali s problemima u Glusteru. Pomno prateći korištenje memorije i vrijeme čekanja diskova, došli smo do preopterećenja, visokog iowaita, grešaka jezgre (kernel oops), zastoja itd.

Ovaj članak rezultat je mnogih eksperimenata s podešavanjem parametara provedenih u raznim situacijama. Zahvaljujući tim parametrima, ne samo da se poboljšala opća odzivnost, već se i rad klastera značajno stabilizirao.

Kada je riječ o podešavanju memorije, prvo što treba pogledati je podsustav virtualne memorije (VM, virtual memory), koji ima mnogo opcija koje vas mogu zbuniti.

vm.swappiness

Parametar vm.swappiness određuje koliko jezgra koristi swapping (swap, podizanje) u usporedbi s radnom memorijom. U izvornoj šifri također je definiran kao „sklonost krađi mapirane memorije“. Visoka vrijednost swappiness znači da je jezgra sklonija ispuštanju mapiranih stranica. Niska vrijednost swappiness znači suprotno: jezgra će manje ispuštati stranice iz memorije. Drugim riječima, što je viša vrijednost vm.swappiness, to će više sustav koristiti swap.

Veliko korištenje swappinga nije poželjno, jer se u radnu memoriju učitavaju i isprazne ogromni blokovi podataka. Mnogi tvrde da bi vrijednost swapiness trebala biti visoka, ali prema mom iskustvu, povećanje performansi donosi postavljanje na „0“.

Više informacija možete pročitati ovdje — lwn.net/Articles/100978

Međutim, ovi postavke trebaju se primjenjivati oprezno i samo nakon testiranja određenog aplikacije. Za aplikacije s visokim opterećenjem, ovu vrijednost treba postaviti na "0". Postavljanjem na "0" poboljšava se odziv sustava.

vm.vfs_cache_pressure

Ovaj parametar kontrolira memoriju koju jezgra koristi za keširanje objekata direktorija i indekse (dentry i inode).

Pri zadanoj vrijednosti od 100, jezgra će pokušati osloboditi cache dentry i inode "pravedno" u odnosu na pagecache i swapcache. Smanjenje vfs_cache_pressure uzrokuje da jezgra zadrži keš dentry i inode. Kada je vrijednost "0", jezgra nikada neće osloboditi keš dentry i inode zbog nedostatka memorije, što lako može dovesti do greške 'out-of-memory'. Povećanje vfs_cache_pressure iznad 100 daje prioritet ispuštanju dentry i inode.

Kada se koristi GlusterFS, mnogi korisnici s velikim količinama podataka i malim datotekama lako mogu iskoristiti značajnu količinu operativne memorije na serveru zbog keširanja inode/dentry, što može dovesti do smanjenja performansi, jer jezgra mora obraditi strukture podataka u sustavu s 40 GB memorije. Povećanje ovog parametra iznad 100 pomoglo je mnogim korisnicima da postignu pravednije keširanje i poboljšaju odziv jezgre.

vm.dirty_background_ratio i vm.dirty_ratio

Prvi parametar (vm.dirty_background_ratio) određuje postotak memorije s prljavim stranicama, pri čemu se mora započeti pozadinsko ispuštanje prljavih stranica na disk. Dok se ovaj postotak ne postigne, stranice se ne ispuštaju na disk. Kada ispuštanje započne, odvija se u pozadini, bez prekidanja aktivnih procesa.

Drugi parametar (vm.dirty_ratio) određuje postotak memorije koji može biti zauzet neurednim stranicama prije nego što započne prisilno ispuštanje (forced flash). Kada se dostigne ovaj prag, svi procesi postaju sinkroni (blokirani) i ne smiju nastaviti raditi sve dok njihova zatražena ulazno-izlazna operacija ne bude stvarno završena i podaci ne budu pohranjeni na disku. Pri visokom opterećenju ulazno-izlaznih operacija to uzrokuje problem, jer keširanje podataka izostaje i svi procesi koji provode ulazno-izlazne operacije su blokirani čekajući ulazno-izlazne operacije. To dovodi do velike količine blokiranih procesa, visokog opterećenja, nestabilnog rada sustava i loše izvedbe.

Smanjenje vrijednosti ovih parametara dovodi do toga da se podaci češće ispuštaju na disk i ne pohranjuju u RAM-u. To može pomoći sustavima s velikim količinama memorije, za koje je normalno ispuštati keš stranica veličine 45–90 GB na disk, što dovodi do ogromnog vremena čekanja za frontend aplikacije, smanjujući ukupnu responzivnost i interaktivnost.

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

Keš stranica (page cache) je keš u kojem se pohranjuju podaci datoteka i izvršnih programa, tj. to su stranice s stvarnim sadržajem datoteka ili blokovnih uređaja. Ovaj keš se koristi za smanjenje broja čitanja s diska. Vrijednost «1» znači da se za keš koristi 1% RAM-a i da će biti više operacija čitanja s diska nego iz RAM-a. Nije nužno mijenjati ovu vrijednost, ali ako ste paranoični u vezi kontrole nad kešem stranica, možete je iskoristiti.

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

Planirator ulazno-izlaznih operacija (I/O scheduler) je komponenta Linux jezgri koja obrađuje redove čitanja i pisanja. Teoretski, za pametan RAID kontroler bolje je koristiti «noop», jer Linux ništa ne zna o fizičkoj geometriji diska, stoga je učinkovitije dopustiti kontroleru, koji dobro poznaje geometriju diska, da što brže obradi zahtjev. No, čini se da «deadline» povećava izvedbu. Više o planiratorima može se pročitati u dokumentaciji izvorne jezgri Linuxa: linux/Documentation/block/*osched.txt. I također sam primijetio povećanje propusnosti čitanja tijekom miješanih operacija (puno operacija pisanja).

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

Broj ulazno-izlaznih zahtjeva u predmemoriji prije nego što budu poslani planeru. Veličina unutarnje queue nekih kontrolera (queue_depth) veća je od nr_requests planera ulazno-izlaznih zahtjeva, što znači da planer ima malo šansi ispravno prioritizirati i izvršiti spajanje zahtjeva. Za planere deadline i CFQ bolje je kada je nr_requests dvostruko veći od unutarnje queue kontrolera. Spajanje i preuređivanje zahtjeva pomaže planeru da bude responzivniji pri velikom opterećenju.

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

Parametar page-cluster upravlja brojem stranica koje se istovremeno zapisuju u swap. U gornjem primjeru, vrijednost se postavlja na «16» prema veličini stripea (stripe size) RAID-a od 64 KB. To nema smisla kada je swappiness = 0, ali ako ste postavili swappiness na 10 ili 20, korištenje ove vrijednosti će vam pomoći kada je veličina stripea RAID-a 64 KB.

blockdev --setra 4096 /dev/`<`naziv uređaja`>` (-sdb, hdc ili dev_mapper)

Postavke blok uređaja prema zadanim postavkama za mnoge RAID kontrolere često rezultiraju lošim performansama. Dodavanje gore navedene opcije podešava predmemoriju za čitanje na 4096 * 512-bajtnih sektora. Bare, za stream operacije povećava brzinu punjenja ugrađene predmemorije diska zahvaljujući proaktivnom čitanju tijekom razdoblja koje operativni sustav troši na pripremu ulazno-izlaznih zahtjeva. U predmemoriju mogu otići podaci koji će biti zatraženi prilikom sljedećeg čitanja. Preveliko proaktivno čitanje može ubiti slučajni ulazno-izlaz za velike datoteke, ako koristi potencijalno korisno vrijeme diska ili učitava podatke izvan predmemorije.

U nastavku su još neki savjeti na razini datotečnog sustava. No, oni još nisu testirani. Osigurajte da vaš datotečni sustav zna veličinu stripea i broj diska u nizu. Na primjer, da je to RAID 5 s veličinom stripea 64K od šest diskova (zapravo pet, jer jedan disk se koristi za parnost). Ovi savjeti su temelji na teorijskim pretpostavkama i prikupljeni su iz raznih blogova/stavova stručnjaka za RAID.

-> ext4 fs, 5 diskova, 64K stripe, jedinice u 4K blokovima
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 diskova, 64K stripe, jedinice u 512-bajtnim sektorima
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))

Za velike datoteke razmotrite mogućnost povećanja gore navedenih veličina stripeova.

PAŽNJA! Sve što je gore opisano izuzetno je subjektivno za neke tipove aplikacija. Ovaj članak ne jamči nikakva poboljšanja bez prethodnog testiranja relevantnih aplikacija od strane korisnika. Treba ga primijeniti samo u slučaju potrebe za poboljšanjem opće odzivnosti sustava ili ako rješava trenutne probleme.