Përkthimi i artikullit është përgatitur në prag të fillimit të kursit .
Herë pas here, shfaqen pyetje rreth rekomandimeve të Gluster për konfigurimin e bërthamës dhe nëse ka ndonjë nevojë për to.
Një nevojë e tillë ndodhi rrallë. Në shumicën e ngarkesave, bërthama funksionon shumë mirë. Megjithatë, ka dhe një anë tjetër. Historikisht, bërthama Linux është e gatshme të konsumojë shumë memorie, nëse i jepet mundësia, përfshirë për memorizimin si mënyra kryesore për të përmirësuar performancën.
Në shumicën e rasteve, kjo funksionon shkëlqyeshëm, por në ngarkesa të mëdha mund të çojë në probleme.
Ne kemi një përvojë të gjerë me sisteme që konsumojnë shumë memorie, si CAD, EDA dhe të ngjashme, të cilat kanë filluar të ngadalësohen nën ngarkesa të larta. Dhe ndonjëherë kemi hasur probleme me Gluster. Pas një vëzhgimi të kujdesshëm për disa ditë mbi memorjen e përdorur dhe kohën e pritjes së disqeve, ne hasëm në ngarkesë, një iowait shumë të madh, gabime në bërthamë (kernel oops), dhe bllokime etj.
Ky artikull është rezultat i eksperimentimeve të shumta me 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 edhe funksionimi i klasterit u stabilizua ndjeshëm.
Kur bëhet fjalë për konfigurimin e memories, e para që duhet të shikoni është nën-sistemi i memories virtuale (VM, virtual memory), të cilin ka shumë mundësi që mund t'ju ngatërrojnë.
vm.swappiness
Parametri vm.swappiness përcakton se sa shumë bërthama përdor swap-in (në mënyrë krahasuese me memorien operative). Në kodin burimor, ai gjithashtu është përcaktuar si «tendency to steal mapped memory» (tendenca për të vjedhur memorien e mapuar). Një vlerë e lartë swappiness nënkupton se bërthama do të jetë më e prirur të shkarkojë faqet e mapuara. Një vlerë e ulët swappiness nënkupton 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 madh i swap-it është i padëshirueshëm, sepse blloqet e mëdha të të dhënave ngarkohet dhe shkarkohet nga memoria operative. Shumë pretendojnë se vlera e swapiness duhet të jetë e madhe, por nga përvoja ime, instalimi në «0» çon në një rritje të performancës.
Mund të lexoni më shumë këtu —
Por, sërish, këto настройки duhet të aplikohen me kujdes dhe vetëm pas testimit të aplikacionit specifik. Për aplikacionet e ngarkuara me flukse të larta, ky parameter duhet vendosur në «0». Duke e ndryshuar në «0», përmirësohet përgjigjshmëria e sistemit.
vm.vfs_cache_pressure
Ky parameter kontrollon memorien e konsumuar nga bërthama për memorizimin e objekteve të katalogëve dhe indeksëve të descriptors (dentry dhe inode).
Me një vlerë të paracaktuar prej 100, bërthama do të përpiqet të çlirojë cache-in e dentry dhe inode në mënyrë «të drejtë» në lidhje me pagecache dhe swapcache. Ulja e vfs_cache_pressure çon në ruajtje të caches dentry dhe inode nga bërthama. Kur vlera është «0», bërthama kurrë nuk do të pastrohet cache-in e dentry dhe inode për shkak të mungesës së memories (memory pressure), dhe këtë mund të çojë lehtësisht në një gabim out-of-memory. Rritja e vfs_cache_pressure përtej 100 çon në këtë që bërthama i jep përparësi shkarkimit të dentry dhe inode.
Kur përdoret GlusterFS, shumë përdorues me sasi të mëdha të të dhënave dhe shumë skedarë të vegjël mund të përdorin lehtësisht një sasi të konsiderueshme të memories operative në server për shkak të memorizimit të inode/dentry, që mund të çojë në një rënie të performancës, pasi bërthama duhet të procesojë strukturat e të dhënave në një sistem me 40 GB memorie. Vendosja e këtij parametri mbi 100 ndihmoi shumë përdorues të arrijnë memorizim më të drejtë dhe të përmirësojnë përgjigjshmërinë e bërthamës.
vm.dirty_background_ratio dhe vm.dirty_ratio
Parametri i parë (vm.dirty_background_ratio) përcakton përqindjen e memories me faqe të ndyra, duke arritur të cilën duhet të fillojë një shkarkim të fushës së ndyshme në disk. Deri sa ky përqindje nuk arrihet, faqet nuk shkarkohen në disk. Dhe kur fillon shkarkimi, ai realizohet në mënyrë të prapambetur, pa ndërprerë proceset aktive.
Parametri i dytë (vm.dirty_ratio) përcakton përqindjen e memories që mund të zëni nga faqet e ndotura deri në fillimin e shlyerjes me forcë (forced flash). Pasi të arrihet ky prag, të gjithë proceset bëhen sinkronike (bllokohen), dhe nuk u lejohet të vazhdojnë punën deri sa operacioni i tyre i kërkuar i hyrjes-daljes të përfundojë ndryshe dhe të dhënat të ndodhin në disk. Kur hyni shumë në hyrje-dalje, kjo krijon një problem, pasi ndodhet mungesa e keqëtë këshillimit të të dhënave dhe të gjitha proceset që kryejnë hynë-dalje bllokohen duke pritur hyrjen-daljen. Kjo çon në një numër të madh të proceseve të bllokuar, ngarkesë të lartë, funksionim jo stabil të sistemit dhe performancë të dobët.
Ulja e vlerave të këtyre parametrave çon në faktin që të dhënat përfundojnë më shpesh në disk dhe nuk ruhet në RAM. Kjo mund t’i ndihmojë sistemet me shumë memorie, për të cilat nuk është e pazakontë të hiqen për në disk cache faqesh prej 45–90 GB, gjë që çon në një kohë të madhe prite për aplikacionet frontend, duke reduktuar përgjigjen dhe interaktivitetin e përgjithshëm.
«1» > /proc/sys/vm/pagecache
Cache i faqeve (page cache) është cache ku ruhet të dhënat e fileve dhe programeve të ekzekutueshme, pra janë faqet me përmbajtje reale të fileve ose pajisjeve bllok. Ky cache përdoret për të reduktuar numrin e leximeve nga disku. Vlera «1» do të thotë se për cache përdoret 1% e RAM dhe operacionet e leximit nga disku do të jenë më shumë sesa nga RAM. Nuk është domosdoshmëri ta ndryshoni këtë parametrash, por nëse keni një qëndrim paranoid mbi kontrollimin e cache të faqeve, mund ta shfrytëzoni atë.
«deadline» > /sys/block/sdc/queue/scheduler
Planifikuesi i hyrjes-daljes (I/O scheduler) është një komponent i bërthamës Linux që trajton radhët për lexim dhe shkrim. Në teori, për një kontrollues RAID të mençur është më mirë të përdoret «noop», sepse Linux nuk di asgjë për gjeometrinë fizike të disku, andaj është më efektive t’i lejohet kontrolluesit, që e njeh mirë strukturën e disku, të përpunojë kërkesat sa më shpejt. Por duket se «deadline» e përmirëson performancën. Më shumë për planifikuesit mund të lexoni në dokumentacionin e kodit burimor të bërthamës Linux: linux/Documentation/block/*osched.txt. Dhe gjithashtu kam vërejtur 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ë input-it dhe output-it në buffer para se t'i kalohen planifikuesit. Madhësia e radhës brenda disa kontrolluesve (queue_depth) është më e madhe se nr_requests e planifikuesit të input-it dhe output-it, kështu që planifikuesi ka pak gjasa të përprioritojë dhe të kryejë korrektësisht bashkimet e kërkesave. Për planifikuesit deadline dhe CFQ, është më mirë kur nr_requests është dy herë më shumë se radhës brenda kontrolluesit. Bashkimi dhe riorganizimi i kërkesave ndihmon planifikuesin të jetë më reagues në ngarkesa të mëdha.
echo «16» > /proc/sys/vm/page-cluster
Parametri page-cluster menaxhon numrin e faqeve që shkruhen në swap njëherësh. Në shembullin e mësipërm, vlera vendoset në «16» në përputhje me madhësinë e stripe (stripe size) të RAID-it që është 64 KB. Kjo nuk ka kuptim kur swappiness = 0, por nëse e keni vendosur swappiness në 10 ose 20, atëherë përdorimi i kësaj vlere do t'ju ndihmojë kur madhësia e stripe-it të RAID-it është 64 KB.
blockdev —setra 4096 /dev/<emri i pajisjes> (-sdb, hdc ose dev_mapper)
Caktimet e pajisjeve bllok normale për shumë kontrollues RAID zakonisht çojnë në performancë të tmerrshme. Shtimi i opsionit të mësipërm konfiguroni leximin e parashikimit për sektorë prej 4096 * 512 byte. Të paktën për operacione të rrjedhshme, shpejtësia rritet përmbush duke mbushur të dhënat e ndërtuara në cache-në e çastit duke lexuar në mënyrë të parashikueshme në periudhën që bërthama përdor për përgatitjen e input-it dhe output-it. Në cache mund të ruhen të dhënat që do të kërkohen gjatë leximit të ardhshëm. Leximi i tepërt i parashikimit mund të vrasë input-in dhe output-in e rastësishëm për skedarë të mëdhenj, nëse përdor kohën e mundshme të diskut ose ngarkon të dhëna përtej cache-it.
Më poshtë janë disa rekomandime të tjera në nivelin e sistemit të skedarëve. Por ato ende nuk janë testuar. Sigurohuni që sistemi juaj i skedarëve e di madhësinë e stripe-it dhe numrin e disqeve në grumbull. Për shembull, që ky është një grumbull raid5 me madhësi stripe 64K nga gjashtë disqe (në fakt nga pesë, sepse një disk përdoret për paritet). Këto rekomandime janë të bazuara në supozime teorike dhe janë mbledhur nga blogje të ndryshme/artikuj ekspertësh për RAID.
-> skedarë ext4, 5 disqe, 64K stripe, njësitë në blloqe 4K
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disqe, 64K stripe, njësitë në sektorë prej 512 byte
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))Për skedarë të mëdhenj, mund të shqyrtohet mundësia e rritjes së madhësive të mësipërme të stripeve.
KËSHILLIM! Të gjitha që janë përshkruar më sipër janë 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. Duhet të aplikohet vetëm në rast se nevojitet përmirësimi i përgjithshëm i përgjigjeve të sistemit ose nëse zgjidh probleme aktuale.
Materiale shtesë:
Lexoni më shumë
Burimi: habr.com
