Prijevod članka pripremljen je uoči početka kursa .
Povremeno, tu i tamo, postavljaju se pitanja o Glusterovim preporukama u vezi podešavanja kernela i da li postoji potreba za tim.
Takva potreba se rijetko javlja. Na većini radnih opterećenja, kernel radi vrlo dobro. Iako postoji loša strana. Istorijski gledano, Linux kernel je bio spreman da troši mnogo memorije ako mu se pruži prilika, uključujući i keširanje kao glavni način za poboljšanje performansi.
U većini slučajeva ovo funkcionira dobro, ali pod velikim opterećenjem može dovesti do problema.
Imamo dosta iskustva sa sistemima koji intenzivno koriste memoriju kao što su CAD, EDA i slični, koji su počeli da usporavaju pod velikim opterećenjem. A ponekad smo nailazili na probleme u Glusteru. Nakon pažljivog praćenja upotrebe memorije i latencije diska tokom mnogo dana, dobili smo njihovo preopterećenje, ogromno čekanje, greške kernela (kernel ups), zamrzavanje itd.
Ovaj članak je rezultat mnogih eksperimenata podešavanja izvedenih u različitim situacijama. Zahvaljujući ovim parametrima, ne samo da je poboljšan ukupni odziv, već se i klaster značajno stabilizovao.
Kada je u pitanju podešavanje memorije, prvo na šta treba obratiti pažnju je podsistem virtuelne memorije (VM, virtuelna memorija), koji ima veliki broj opcija koje vas mogu zbuniti.
vm.swappiness
Parametar vm.swappiness određuje koliko kernel koristi swap (swap, paging) u odnosu na RAM. Također je definirana u izvornom kodu kao "sklonost krađi mapirane memorije". Visoka swappiness znači da će kernel biti skloniji zamjeni mapiranih stranica. Niska vrijednost zamjene znači suprotno: kernel će manje stranica iz memorije. Drugim riječima, što je veća vrijednost vm.swappiness, to će sistem više koristiti swap.
Velika upotreba zamjene je nepoželjna, jer se ogromni blokovi podataka učitavaju i istovaruju u RAM. Mnogi ljudi tvrde da bi vrijednost zamjene trebala biti velika, ali prema mom iskustvu, postavljanje na "0" dovodi do boljih performansi.
Više možete pročitati ovdje -
Ali, opet, ove postavke treba pažljivo primijeniti i tek nakon testiranja određene aplikacije. Za visoko opterećene streaming aplikacije, ovaj parametar treba postaviti na "0". Kada se promijeni na "0", odziv sistema se poboljšava.
vm.vfs_cache_pressure
Ova postavka kontrolira memoriju koju kernel troši za keširanje direktorija i inode objekata (dentry i inode).
Sa podrazumevanom vrednošću od 100, kernel će pokušati da oslobodi keš memorije dentry i inode na "fer" osnovi za keš memorije stranice i swapcache. Smanjenje vfs_cache_pressure uzrokuje da kernel zadržava dentry i inode kešove. Kada je vrijednost "0", kernel nikada neće isprazniti dentry i inode keš memoriju zbog pritiska memorije, a to može lako dovesti do greške u nedostatku memorije. Povećanje vfs_cache_pressure iznad 100 uzrokuje da kernel daje prioritet dentry i inode flushing.
Kada koriste GlusterFS, mnogi korisnici sa velikim količinama podataka i mnogo malih datoteka mogu lako koristiti značajnu količinu RAM-a na serveru zbog inode/dentry keširanja, što može dovesti do degradacije performansi jer kernel mora obraditi strukture podataka na sistemu sa 40 GB memorije. Postavljanje ove vrijednosti 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 sa prljavim stranicama, nakon dostizanja kojeg je potrebno započeti ispiranje prljavih stranica u pozadini na disk. Dok se ovaj procenat ne dostigne, nijedna stranica se ne ispušta na disk. A kada resetovanje počne, radi u pozadini bez prekidanja pokrenutih procesa.
Drugi parametar (vm.dirty_ratio) definira postotak memorije koju mogu zauzeti prljave stranice prije početka prisilnog blica. Jednom kada se dostigne ovaj prag, svi procesi postaju sinhroni (blokirani) i nije im dozvoljeno da nastave sve dok se I/O koji su tražili stvarno ne dovrši i podaci se ne nalaze na disku. Sa teškim I/O, ovo uzrokuje problem jer nema keširanja podataka i svi procesi koji rade I/O su blokirani čekajući I/O. To dovodi do velikog broja zakačenih procesa, velikog opterećenja, nestabilnosti sistema i loših performansi.
Smanjenje ovih postavki uzrokuje da se podaci češće ispuštaju na disk i ne pohranjuju u RAM. Ovo može pomoći sistemima koji opterećuju memoriju gdje je normalno izbaciti keš memorije stranica od 45-90 GB na disk, što rezultira velikim kašnjenjem za front-end aplikacije, smanjujući ukupni odziv i interaktivnost.
"1" > /proc/sys/vm/pagecache
Predmemorija stranica je keš memorija koja pohranjuje podatke datoteka i izvršnih programa, odnosno to su stranice sa stvarnim sadržajem datoteka ili blok uređaja. Ova keš memorija se koristi za smanjenje broja čitanja diska. Vrijednost "1" znači da se 1% RAM-a koristi za keš memoriju i da će biti više čitanja s diska nego iz RAM-a. Nije potrebno mijenjati ovu postavku, ali ako ste paranoični u pogledu kontrole keša stranice, možete je koristiti.
"rok" > /sys/block/sdc/queue/scheduler
I/O planer je komponenta jezgre Linuxa koja rukuje redovima za čitanje i pisanje. U teoriji, bolje je koristiti "noop" za pametni RAID kontroler, jer Linux ne zna ništa o fizičkoj geometriji diska, pa je efikasnije pustiti kontroler, koji dobro poznaje geometriju diska, da obradi zahtjev što je brže moguće. moguće. Ali izgleda da "rok" poboljšava performanse. Više o planerima možete pročitati u dokumentaciji izvornog koda Linux kernela: linux/Documentation/block/*osched.txt. Takođe sam video povećanje propusnosti čitanja tokom mešovitih operacija (mnogo pisanja).
"256" > /sys/block/sdc/queue/nr_requests
Broj I/O zahtjeva u međuspremniku prije nego što se proslijede planeru. Veličina internog reda nekih kontrolera (queue_depth) je veća od nr_requests I/O planera, tako da I/O planer ima male šanse da pravilno odredi prioritete i spoji zahtjeve. Za planere rokova i CFQ, bolje je kada je nr_requests 2 puta veći od internog reda kontrolora. Spajanje i preuređivanje zahtjeva pomaže planeru da bolje reagira pod velikim opterećenjem.
echo "16" > /proc/sys/vm/page-cluster
Parametar klaster stranica kontrolira broj stranica koje su upisane u zamjenu u jednom trenutku. U gornjem primjeru, vrijednost je postavljena na "16" prema veličini RAID trake od 64 KB. Nema smisla sa swappiness = 0, ali ako postavite swappiness na 10 ili 20 onda će vam korištenje ove vrijednosti pomoći kada je veličina RAID trake 64K.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc ili dev_mapper)
Zadane postavke blok uređaja za mnoge RAID kontrolere često rezultiraju užasnim performansama. Dodavanjem gornje opcije postavlja se čitanje unaprijed za sektore od 4096 * 512 bajta. U najmanju ruku, za operacije striminga, brzina se povećava punjenjem keša diska na čipu sa čitanjem unaprijed tokom perioda koji kernel koristi za pripremu I/O. Keš memorija može sadržavati podatke koji će biti zatraženi pri sljedećem čitanju. Previše preddohvaćanja može ubiti nasumični I/O za velike datoteke ako troši potencijalno korisno vrijeme na disku ili učitava podatke izvan keša.
Ispod je još nekoliko preporuka na nivou sistema datoteka. Ali još nisu testirani. Uvjerite se da vaš sistem datoteka zna veličinu trake i broj diskova u nizu. Na primjer, da je ovo 5K stripe raid64 niz od šest diskova (u stvari pet, jer se jedan disk koristi za paritet). Ove preporuke su zasnovane na teorijskim pretpostavkama i sastavljene od različitih blogova/članaka od strane stručnjaka za RAID.
-> 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))Za velike datoteke razmislite o povećanju veličine traka navedenih iznad.
PAŽNJA! Sve gore opisano je vrlo subjektivno za neke vrste aplikacija. Ovaj članak ne jamči nikakva poboljšanja bez prethodnog korisničkog testiranja povezanih aplikacija. Treba ga koristiti samo ako je potrebno poboljšati ukupnu odzivnost sistema, ili ako rješava trenutne probleme.
Dodatni materijali:
Čitaj više
izvor: www.habr.com