Përkthimi i artikullit është përgatitur para fillimit të kursit .
Herë pas here shfaqen pyetje mbi rekomandimet e Gluster për konfigurimin e bërthamës dhe nëse ka nevojë për atë.
Kjo nevojë ndodh rrallë. Në shumicën e ngarkesave, bërthama funksionon shumë mirë. Megjithatë, ka edhe një anë tjetër. Historikisht, bërthama Linux merr shumë memorie nëse i jepet mundësia, përfshirë për memorizimin e informacionit si mënyra kryesore për të përmirësuar performancën.
Në shumicën e rasteve, kjo punon shumë mirë, por me ngarkesë të madhe mund të shkaktojë probleme.
Ne kemi një përvojë të madhe me sisteme që konsumojnë shumë memorie, si CAD, EDA dhe të ngjashme, të cilat filluan të ngadalësohen nën ngarkesë të lartë. Dhe ndonjëherë hasëm në probleme me Gluster. Pas një vëzhgimi të hollësishëm për disa ditë mbi përdorimin e memories dhe kohën e pritjes së disqeve, e kuptuam se kishim mbingarkesë, pritje të madhe të i/o, gabime të bërthamës (kernel oops), ngrirje dhe të tjera.
Ky artikull është rezultat i shumë eksperimenteve për konfigurimin e parametrave, të kryera në situata të ndryshme. Falë këtyre parametrave, jo vetëm që u përmirësua përgjigjshmëria në përgjithësi, por gjithashtu u stabilizua ndjeshëm funksionimi i klasterit.
Kur bëhet fjalë për konfigurimin e memories, gjëja e parë që duhet parë është nën-sistemi i memories virtuale (VM, virtual memory), i cili ka një numër të madh opsionesh që mund t'ju ngatërrojnë.
vm.swappiness
Parametri vm.swappiness kufizon se sa bërthama përdor swapimin (swap, përkthim) në krahasim me memorien operative. Në kodin burimor, ai gjithashtu përcaktohet si «tendency to steal mapped memory» (prirja për të vjedhur memorien e mapuar). Një vlerë e lartë e swappiness do të thotë se bërthama do të jetë më e prirur për të shkarkuar faqet e mapuara. Një vlerë e ulët e swappiness do të thotë të kundërtën: bërthama do të shkarkojë më pak faqe nga memoria. Në fjalë të tjera, sa më e lartë të jetë vlera vm.swappiness, aq më shumë sistemi do të përdorë swap.
Përdorimi i lartë i swap-it nuk është e dëshirueshme, pasi ngarkohen dhe shkarkohen blloqe të mëdha të dhënash në memorien operative. Shumë thonë se vlera e swapiness duhet të jetë e lartë, por sipas përvojës time, rritja e performancës arrihet duke vendosur në «0».
MĂ« shumĂ« mund tĂ« lexoni kĂ«tu â
Por, përsëri, këto cilësime duhet të aplikohen me kujdes dhe vetëm pas testimit të aplikacionit të veçantë. Për aplikacionet me ngarkesë të lartë të transmetimit, ky parametër duhet të vendoset në "0". Duke e ndryshuar në "0", përgjigjshmëria e sistemit përmirësohet.
vm.vfs_cache_pressure
Ky parametër kontrollon kujtesën e konsumuar nga bërthama për të ruajtur objekte katalogu dhe indeksin e të dhënave (dentry dhe inode).
Me një vlerë parazgjedhje prej 100, bërthama do të përpiqet të lirojë ndihmën e dentry dhe inode në mënyrë "të drejtë" në raport me pagecache dhe swapcache. Reduktimi i vfs_cache_pressure bën që bërthama të mbajë ndihmën e dentry dhe inode. Kur vlera është "0", bërthama nuk do të pastrojë kurrë ndihmën e dentry dhe inode për shkak të mungesës së kujtesës (memory pressure), dhe kjo mund të çojë lehtë në një gabim out-of-memory. Rritja e vfs_cache_pressure për më shumë se 100 bën që bërthama të japë prioritet për shkarkimin e dentry dhe inode.
Kur përdoret GlusterFS, shumë përdorues me sasi të mëdha të dhënash dhe shumë skedarë të vegjël mund të përdorin në server një sasi të konsiderueshme të kujtesës për shkak të ruajtjes së inode/dentry, e cila mund të çojë në uljen e performancës, pasi bërthama duhet të përballojë strukturat e të dhënave në një sistem me 40 GB kujtesë. Vendosja e këtij parametri mbi 100 ka ndihmuar shumë përdorues të arrijnë ruajtje më të drejtë dhe të përmirësojnë përgjigjshmërinë e bërthames.
vm.dirty_background_ratio dhe vm.dirty_ratio
Parametri i parë (vm.dirty_background_ratio) përcakton përqindjen e kujtesës me faqe të ndyrë, arritja e të cilës duhet të fillojë një rikthim në sfond të faqeve të ndyrë në disk. Derisa ky përqindje të mos arrihet, faqe nuk do të kthehen në disk. Dhe kur rikthimi fillon, ai realizohet në sfond, pa ndërprerë proceset në punë.
Parametri i dytë (vm.dirty_ratio) përcakton përqindjen e memories që mund të zënë faqet e ndotura para fillimit të shkarkimit të detyrueshëm (forced flash). Kur arrihet ky prag, të gjithë proceset bëhen sinkronike (blokohen) dhe nuk u lejohet të vazhdojnë punën derisa operacioni i kërkuar i hyrjes/daljes të përfundojë në mënyrë faktike dhe të dhënat të jenë në disk. Në hyrje/dalje me ngarkesë të lartë, kjo shkakton probleme, pasi ndodhet mungesa e cache-it të të dhënave, dhe të gjithë proceset që kryejnë hyrje/dalje bllokohen duke pritur për hyrje/dalje. Kjo çon në një numër të madh procesesh që ngecin, ngarkesë të lartë, funksionim të paqëndrueshëm të sistemit dhe performancë të dobët.
Reduktimi i vlerave tĂ« kĂ«tyre parametrave çon nĂ« gjendjen qĂ« tĂ« dhĂ«nat shkarkohen mĂ« shpesh nĂ« disk dhe nuk ruajnĂ« nĂ« RAM. Kjo mund tĂ« ndihmojĂ« sistemet me shumĂ« memorie, pĂ«r tĂ« cilat Ă«shtĂ« normale tĂ« shkarkojnĂ« nĂ« disk cache tĂ« faqeve me madhĂ«si 45â90 GB, qĂ« çon nĂ« kohĂ« tĂ« mĂ«dha pritjeje pĂ«r aplikacionet nĂ« frontend, duke ulur pĂ«rgjigjen dhe ndĂ«rveprimin e pĂ«rgjithshĂ«m.
«1» > /proc/sys/vm/pagecache
Cache-i i faqeve (page cache) është cache ku ruhen të dhënat e skedareve dhe programeve të ekzekutueshme, pra janë faqet me përmbajtje faktike të skedareve ose pajisjeve të bllokut. Kjo cache përdoret për të zvogëluar numrin e leximeve nga disku. Vlera «1» do të thotë që për cache përdoret 1% e RAM dhe operacionet e leximit nga disku do të jenë më të shumta se ato nga RAM. Nuk është e nevojshme të ndryshoni këtë parametrin, por nëse jeni paranojak në lidhje me kontrollin mbi cache-in e faqeve, mund ta përdorni.
«deadline» > /sys/block/sdc/queue/scheduler
Planifikuesi i hyrje/daljes (I/O scheduler) është një komponent i bërthamës Linux, i cili përpunon radhët e leximit dhe shkruarjes. Në teori, për një kontrollues RAID inteligjent, është më mirë të përdorni «noop», sepse Linux nuk di asgjë për gjeometrinë fizike të diskut, prandaj është më efektive të lejohet kontrolluesi, i cili e njeh mirë gjeometrinë e diskut, të përpunojë kërkesën sa më shpejt të jetë e mundur. Por duket se «deadline» rrit performancën. Më shumë rreth planifikuesve mund të lexoni në dokumentacionin e kodit burimor të bërthamës Linux: linux/Documentation/block/*osched.txt. Dhe gjithashtu kam vënë re një rritje të kapacitetit të leximit gjatë operacioneve të përziera (shumë operacione shkrimi).
«256» > /sys/block/sdc/queue/nr_requests
Numri i kërkesave të hyrje-dalih në buffer para se ato t'i kalohen planifikuesit. Madhësia e radhës së brendshme të disa kontrolerëve (queue_depth) është më e madhe se nr_requests e planifikuesit të hyrje-dalih, kështu që planifikuesi ka pak mundësi për të priorizuar dhe realizuar bashkimin e kërkesave në mënyrë të saktë. Për planifikuesit deadline dhe CFQ, është më mirë që nr_requests të jetë dy herë më i madh se radhës së brendshme të kontrolerëve. Bashkimi dhe riorganizimi i kërkesave ndihmojnë planifikuesin të jetë më reagues gjatë ngarkesave të mëdha.
echo «16» > /proc/sys/vm/page-cluster
Parametri page-cluster menaxhon numrin e faqeve që shkruhen në swap një herë. Në shembullin e mësipërm, vlera vendoset në «16» në përputhje me madhësinë e striptit (stripe size) të RAID prej 64 KB. Kjo nuk ka ndonjë kuptim kur swappiness = 0, por nëse e ke vendosur swappiness në 10 ose 20, përdorimi i kësaj vlere do t'ju ndihmojë kur madhësia e striptit RAID është 64 KB.
blockdev âsetra 4096 /dev/<emri_ijon> (-sdb, hdc ose dev_mapper)
CilĂ«simet e pajisjeve bllok po default pĂ«r shumĂ« kontrolerĂ« RAID shpesh çojnĂ« nĂ« performancĂ« tĂ« tmerrshme. Shtimi i opsionit tĂ« sipĂ«rpĂ«rmendur, konfiguroni leximin parashikues pĂ«r 4096 * 512-byte sektorĂ«. TĂ« paktĂ«n pĂ«r operacionet e rrjedhĂ«s, rrit efikasitetin duke mbushur ĐșĐ”Ńin e brendshĂ«m tĂ« disks me leximin parashikues gjatĂ«sinĂ« e kohĂ«s qĂ« bĂ«rthama pĂ«rgatit hyrje-dalih. NĂ« ĐșĐ”Ń mund tĂ« vendosen tĂ« dhĂ«nat qĂ« do tĂ« kĂ«rkohen gjatĂ« leximit tĂ« ardhshĂ«m. Leximi parashikues shumĂ« i madh mund tĂ« shkatĂ«rrojĂ« hyrje-dalihin rastĂ«sor pĂ«r skedarĂ«t e mĂ«dhenj, nĂ«se ai pĂ«rdor potencialisht kohĂ«n e dobishme tĂ« disks ose ngarkon tĂ« dhĂ«na pĂ«rtej ĐșĐ”Ńit.
Më poshtë janë disa rekomandime të tjera në nivelin e sistemit të fileve. Por ato ende nuk janë testuar. Sigurohuni që sistemi juaj i skedarëve e di madhësinë e striptit dhe numrin e disqeve në grup. Për shembull, që ky është një grup raid5 me madhësinë e striptit 64K nga gjashtë disqe (me të vërtetë nga pesë, sepse një disk përdoret për paritet). Këto rekomandime janë të bazuara në supozime teorike dhe janë mbledhur nga blogje/artikuj të ekspertëve të RAID.
-> ext4 fs, 5 disqe, 64K stripe, njësitë në 4K blloqe
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disqe, 64K stripe, njësitë në sektorë 512-byte
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))Për skedarët e mëdhenj, mund të shqyrtoni mundësinë për të rritur përmasat e rreshtave të përmendura më sipër.
KĂSHILLĂ! Gjithçka qĂ« Ă«shtĂ« pĂ«rshkruar mĂ« sipĂ«r Ă«shtĂ« jashtĂ«zakonisht subjektive pĂ«r disa lloje aplikacionesh. Ky artikull nuk garanton pĂ«rmirĂ«sime pa testimin paraprak tĂ« aplikacioneve pĂ«rkatĂ«se nga pĂ«rdoruesi. Ai duhet tĂ« pĂ«rdoret vetĂ«m nĂ« rast se pĂ«rmirĂ«son pĂ«rgjigjen e pĂ«rgjithshme tĂ« sistemit ose nĂ«se zgjidh problemet aktuale.
Materiale Shtesë:
Lexo më shumë
Burimi: habr.com
