Përkthimi i artikullit u përgatit në prag të fillimit të kursit .
Periodikisht, aty-këtu, lindin pyetje në lidhje me rekomandimet e Gluster në lidhje me akordimin e kernelit dhe nëse ka nevojë për këtë.
Një nevojë e tillë lind rrallë. Në shumicën e ngarkesave të punës, kerneli funksionon shumë mirë. Edhe pse ka një anë negative. Historikisht, kerneli Linux ka qenë i gatshëm të konsumojë shumë memorie nëse i jepet mundësia, duke përfshirë ruajtjen në memorie si mënyra kryesore për të përmirësuar performancën.
Në shumicën e rasteve, kjo funksionon mirë, por nën ngarkesë të madhe mund të çojë në probleme.
Ne kemi shumë përvojë me sistemet intensive të memories si CAD, EDA dhe të ngjashme, të cilat filluan të ngadalësohen nën ngarkesë të madhe. Dhe ndonjëherë hasëm në probleme në Gluster. Pasi vëzhguam me kujdes përdorimin e kujtesës dhe vonesën e diskut për shumë ditë, morëm mbingarkimin e tyre, pritje të mëdha, gabime kernel (kernel oops), ngrirje, etj.
Ky artikull është rezultat i shumë eksperimenteve akorduese të kryera në situata të ndryshme. Falë këtyre parametrave, jo vetëm përgjegjshmëria e përgjithshme është përmirësuar, por edhe grupi është stabilizuar ndjeshëm.
Kur bëhet fjalë për akordimin e memories, gjëja e parë që duhet parë është nënsistemi i memories virtuale (VM, memorie virtuale), i cili ka një numër të madh opsionesh që mund t'ju ngatërrojnë.
vm.ndërrim
Parametër vm.swappiness përcakton se sa përdor kerneli swap (swap, paging) në krahasim me RAM-in. Përkufizohet gjithashtu në kodin burimor si "prirje për të vjedhur kujtesën e hartuar". Një shkëmbim i lartë do të thotë që kerneli do të jetë më i prirur për të shkëmbyer faqet e hartuara. Një vlerë e ulët e shkëmbimit do të thotë të kundërtën: kerneli do të shfaqet më pak nga memoria. Me fjalë të tjera, aq më e lartë është vlera vm.swappiness, aq më shumë sistemi do të përdorë swap.
Një përdorim i madh i shkëmbimit është i padëshirueshëm, pasi blloqe të mëdha të të dhënave ngarkohen dhe shkarkohen në RAM. Shumë njerëz argumentojnë se vlera e shkëmbimit duhet të jetë e madhe, por në përvojën time, vendosja e saj në "0" çon në performancë më të mirë.
Ju mund të lexoni më shumë këtu -
Por, përsëri, këto cilësime duhet të aplikohen me kujdes dhe vetëm pas testimit të një aplikacioni të caktuar. Për aplikacionet e transmetimit shumë të ngarkuar, ky parametër duhet të vendoset në "0". Kur ndryshohet në "0", reagimi i sistemit përmirësohet.
vm.vfs_cache_pressure
Ky cilësim kontrollon memorien e konsumuar nga kerneli për cachimin e direktorive dhe objekteve inode (dentry dhe inode).
Me një vlerë të paracaktuar prej 100, kerneli do të përpiqet të lirojë memoriet e dhëmbëve dhe inode në një bazë "të drejtë" për cache-in e faqeve dhe swapcache-in. Zvogëlimi i vfs_cache_pressure bën që kerneli të mbajë cache dentry dhe inode. Kur vlera është "0", kerneli nuk do të pastrojë kurrë memorien e dhëmbëve dhe inode për shkak të presionit të memories, dhe kjo mund të çojë lehtësisht në një gabim jashtë memorie. Rritja e vfs_cache_pressure mbi 100 bën që kerneli t'i japë përparësi shpëlarjes së dhëmbëve dhe inodes.
Kur përdorni GlusterFS, shumë përdorues me sasi të mëdha të dhënash dhe shumë skedarë të vegjël mund të përdorin lehtësisht një sasi të konsiderueshme RAM në server për shkak të caching inode/dentry, gjë që mund të çojë në degradim të performancës pasi kerneli duhet të përpunojë strukturat e të dhënave në një sistem me 40 GB memorie. Vendosja e kësaj vlere mbi 100 ka ndihmuar shumë përdorues të arrijnë një memorie më të drejtë dhe reagim të përmirësuar të kernelit.
vm.ratio_dirty_background dhe vm.dirty_ratio
Parametri i parë (vm.dirty_background_ratio) përcakton përqindjen e memories me faqe të ndotura, pasi të arrihet, është e nevojshme të filloni të skuqni faqet e pista në sfond në disk. Derisa të arrihet kjo përqindje, asnjë faqe nuk hidhet në disk. Dhe kur fillon rivendosja, ai funksionon në sfond pa ndërprerë proceset e ekzekutimit.
Parametri i dyte (vm.dirty_ratio) përcakton përqindjen e memories që mund të zënë faqet e pista përpara se të fillojë blici i detyruar. Pasi të arrihet ky prag, të gjitha proceset bëhen sinkron (bllokuar) dhe nuk lejohen të vazhdojnë derisa I/O që ata kanë kërkuar të përfundojë në të vërtetë dhe të dhënat të jenë në disk. Me I/O të rëndë, kjo shkakton një problem sepse nuk ka cache të të dhënave dhe të gjitha proceset që bëjnë I/O janë të bllokuara duke pritur për I/O. Kjo çon në një numër të madh procesesh të varura, ngarkesë të lartë, paqëndrueshmëri të sistemit dhe performancë të dobët.
Zvogëlimi i këtyre cilësimeve bën që të dhënat të shpërndahen më shpesh në disk dhe të mos ruhen në RAM. Kjo mund të ndihmojë sistemet me memorie të rëndë, ku është normale të hidhen memoriet e faqeve 45-90 GB në disk, duke rezultuar në vonesë të madhe për aplikacionet e përparme, duke reduktuar reagimin e përgjithshëm dhe ndërveprim.
"1" > /proc/sys/vm/pagecache
Një cache e faqeve është një memorie e fshehtë që ruan të dhënat e skedarëve dhe programeve të ekzekutueshme, domethënë, këto janë faqe me përmbajtjen aktuale të skedarëve ose pajisje bllokuese. Ky cache përdoret për të zvogëluar numrin e leximeve të diskut. Vlera "1" do të thotë që 1% e RAM-it përdoret për cache dhe do të ketë më shumë lexime nga disku sesa nga RAM. Nuk është e nevojshme ta ndryshoni këtë cilësim, por nëse jeni paranojak për kontrollin e cache-it të faqeve, mund ta përdorni atë.
"afati" > /sys/block/sdc/queue/scheduler
Planifikuesi I/O është një komponent i kernelit Linux që trajton radhët e leximit dhe shkrimit. Në teori, është më mirë të përdoret "noop" për një kontrollues inteligjent RAID, sepse Linux nuk di asgjë për gjeometrinë fizike të diskut, kështu që është më efikase të lini kontrolluesin, i cili e njeh mirë gjeometrinë e diskut, të përpunojë kërkesën sa më shpejt që të jetë e mundur. të mundshme. Por duket se "afati" përmirëson performancën. Mund të lexoni më shumë rreth planifikuesve në dokumentacionin e kodit burimor të kernelit Linux: linux/Documentation/block/*osched.txt. Dhe gjithashtu kam parë një rritje të xhiros së leximit gjatë operacioneve të përziera (shumë operacione shkrimi).
"256" > /sys/block/sdc/queue/nr_requests
Numri i kërkesave I/O në buffer përpara se ato t'i kalohen planifikuesit. Madhësia e radhës së brendshme të disa kontrolluesve (queue_depth) është më e madhe se nr_kërkesat e planifikuesit I/O, kështu që planifikuesi I/O ka pak shanse për t'i dhënë përparësi dhe bashkim të duhur kërkesave. Për planifikuesit e afateve dhe CFQ, është më mirë kur nr_requests është 2 herë më e madhe se radha e brendshme e kontrolluesit. Bashkimi dhe rirenditja e kërkesave e ndihmon planifikuesin të jetë më i përgjegjshëm nën ngarkesë të madhe.
echo "16" > /proc/sys/vm/page-cluster
Parametri i grupit të faqeve kontrollon numrin e faqeve që shkruhen në shkëmbim në të njëjtën kohë. Në shembullin e mësipërm, vlera është vendosur në "16" sipas madhësisë së shiritit RAID prej 64 KB. Nuk ka kuptim me swappiness = 0, por nëse vendosni swappiness në 10 ose 20, atëherë përdorimi i kësaj vlere do t'ju ndihmojë kur madhësia e shiritit RAID është 64K.
blockdev --setra 4096 /dev/<emri i devijimit> (-sdb, hdc ose dev_mapper)
Cilësimet e paracaktuara të bllokut të pajisjes për shumë kontrollues RAID shpesh rezultojnë në performancë të tmerrshme. Shtimi i opsionit të mësipërm konfiguron leximin përpara për sektorët 4096 * 512 byte. Së paku, për operacionet e transmetimit, shpejtësia rritet duke mbushur cache-in e diskut në çip me lexim përpara gjatë periudhës së përdorur nga kerneli për të përgatitur I/O. Cache mund të përmbajë të dhëna që do të kërkohen në leximin e ardhshëm. Shumë marrje paraprake mund të shkatërrojë hyrjen/daljet e rastësishme për skedarë të mëdhenj nëse përdor kohën potencialisht të dobishme të diskut ose ngarkon të dhëna jashtë cache-it.
Më poshtë janë disa rekomandime të tjera në nivelin e sistemit të skedarëve. Por ato nuk janë testuar ende. Sigurohuni që sistemi juaj i skedarëve të dijë madhësinë e shiritit dhe numrin e disqeve në grup. Për shembull, se ky është një grup 5K stripe raid64 me gjashtë disqe (në fakt pesë, sepse një disk përdoret për barazi). Këto rekomandime bazohen në supozime teorike dhe janë përpiluar nga blogje/artikuj të ndryshëm nga ekspertë të 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))Për skedarët e mëdhenj, merrni parasysh rritjen e madhësive të shiritave të listuara më sipër.
KUJDES! Gjithçka e përshkruar më sipër është shumë subjektive për disa lloje aplikimesh. Ky artikull nuk garanton ndonjë përmirësim pa testimin paraprak nga përdoruesi të aplikacioneve përkatëse. Duhet të përdoret vetëm nëse është e nevojshme për të përmirësuar reagimin e përgjithshëm të sistemit, ose nëse zgjidh problemet aktuale.
Materialet shtesë:
Lexo më shumë
Burimi: www.habr.com