Traducerea articolului a fost pregătită în ajunul începerii cursului .
Periodic, ici și colo, apar întrebări cu privire la recomandările lui Gluster privind reglarea nucleului și dacă este nevoie de acest lucru.
O astfel de nevoie apare rar. Pe majoritatea sarcinilor de lucru, nucleul funcționează foarte bine. Deși există un dezavantaj. Din punct de vedere istoric, nucleul Linux a fost dispus să consume multă memorie dacă i s-a oferit ocazia, inclusiv pentru stocarea în cache ca modalitate principală de îmbunătățire a performanței.
În cele mai multe cazuri, acest lucru funcționează bine, dar sub sarcină mare poate duce la probleme.
Avem o mulțime de experiență cu sisteme intensive de memorie, cum ar fi CAD, EDA și altele asemenea, care au început să încetinească sub sarcină grea. Și uneori am întâlnit probleme în Gluster. După ce am observat cu atenție utilizarea memoriei și latența discului timp de multe zile, am primit supraîncărcarea lor, iowait uriaș, erori de kernel (kernel oops), blocări etc.
Acest articol este rezultatul multor experimente de tuning efectuate în diferite situații. Datorită acestor parametri, nu numai răspunsul general s-a îmbunătățit, dar și clusterul s-a stabilizat semnificativ.
Când vine vorba de reglarea memoriei, primul lucru la care trebuie să te uiți este subsistemul memoriei virtuale (VM, memorie virtuală), care are un număr mare de opțiuni care te pot deruta.
vm.schimbări
Parametru vm.swappiness determină cât de mult folosește nucleul swap (swap, paginare) în comparație cu RAM. De asemenea, este definit în codul sursă ca „tendința de a fura memoria mapată”. O schimbare mare înseamnă că nucleul va fi mai înclinat să schimbe paginile mapate. O valoare de schimb scăzută înseamnă contrariul: nucleul va pagina mai puțin din memorie. Cu alte cuvinte, cu cât valoarea este mai mare vm.swappiness, cu atât sistemul va folosi mai mult swap.
O utilizare mare a schimbului este nedorită, deoarece blocuri uriașe de date sunt încărcate și descărcate în RAM. Mulți oameni susțin că valoarea de schimb ar trebui să fie mare, dar din experiența mea, setarea acesteia la „0” duce la o performanță mai bună.
Puteți citi mai multe aici -
Dar, din nou, aceste setări ar trebui aplicate cu grijă și numai după testarea unei anumite aplicații. Pentru aplicațiile de streaming foarte încărcate, acest parametru ar trebui să fie setat la „0”. Când este schimbat la „0”, capacitatea de răspuns a sistemului se îmbunătățește.
vm.vfs_cache_pressure
Această setare controlează memoria consumată de nucleu pentru stocarea în cache a directorului și a obiectelor inode (dentry și inode).
Cu o valoare implicită de 100, nucleul va încerca să elibereze cache-urile dentry și inode pe o bază „echitabilă” pentru pagecache și swapcache. Scăderea vfs_cache_pressure face ca nucleul să păstreze cache-urile dentry și inode. Când valoarea este „0”, nucleul nu va șterge niciodată memoria cache a dentry și inode din cauza presiunii memoriei, iar acest lucru poate duce cu ușurință la o eroare de lipsă de memorie. Creșterea vfs_cache_pressure peste 100 face ca nucleul să prioritizeze spălarea dentry și a inodului.
Atunci când folosesc GlusterFS, mulți utilizatori cu cantități mari de date și multe fișiere mici pot utiliza cu ușurință o cantitate semnificativă de RAM pe server datorită stocării în cache inode/dentry, ceea ce poate duce la degradarea performanței, deoarece nucleul trebuie să proceseze structurile de date pe un sistem. cu 40 GB de memorie. Setarea acestei valori peste 100 a ajutat mulți utilizatori să obțină o stocare mai corectă în cache și o capacitate de răspuns îmbunătățită a nucleului.
vm.dirty_background_ratio și vm.dirty_ratio
Primul parametru (vm.dirty_background_ratio) determină procentul de memorie cu pagini murdare, după ce se ajunge la care este necesar să începeți spălarea paginilor murdare din fundal pe disc. Până la atingerea acestui procent, nicio pagină nu este încărcată pe disc. Și când începe resetarea, rulează în fundal fără a întrerupe procesele de rulare.
Al doilea parametru (vm.dirty_ratio) definește procentul de memorie care poate fi ocupat de paginile murdare înainte de începerea blițului forțat. Odată ce acest prag este atins, toate procesele devin sincrone (blocate) și nu au voie să continue până când I/O pe care le-au solicitat nu este efectiv finalizat și datele sunt pe disc. Cu I/O grele, acest lucru cauzează o problemă deoarece nu există stocare în cache a datelor și toate procesele care fac I/O sunt blocate în așteptarea I/O. Acest lucru duce la un număr mare de procese suspendate, sarcină mare, instabilitate a sistemului și performanță slabă.
Scăderea acestor setări face ca datele să fie spălate pe disc mai des și nu sunt stocate în RAM. Acest lucru poate ajuta sistemele cu memorie grea, unde este normal să ștergeți cache-urile paginilor de 45-90 GB pe disc, rezultând o latență uriașă pentru aplicațiile front-end, reducând capacitatea de răspuns și interactivitatea generală.
„1” > /proc/sys/vm/pagecache
Un cache de pagină este un cache care stochează datele fișierelor și ale programelor executabile, adică acestea sunt pagini cu conținutul real al fișierelor sau dispozitivelor blocate. Acest cache este folosit pentru a reduce numărul de citiri de disc. O valoare de „1” înseamnă că 1% din RAM este utilizat pentru cache și vor fi mai multe citiri de pe disc decât de pe RAM. Nu este necesar să schimbați această setare, dar dacă sunteți paranoic în ceea ce privește controlul cache-ului paginii, o puteți utiliza.
„termen limită” > /sys/block/sdc/queue/scheduler
Planificatorul I/O este o componentă a nucleului Linux care se ocupă de cozile de citire și scriere. În teorie, este mai bine să folosiți „noop” pentru un controler RAID inteligent, deoarece Linux nu știe nimic despre geometria fizică a discului, deci este mai eficient să lăsați controlerul, care cunoaște bine geometria discului, să proceseze cererea cât mai repede. posibil. Dar se pare că „termenul limită” îmbunătățește performanța. Puteți citi mai multe despre programatori în documentația codului sursă al nucleului Linux: linux/Documentation/block/*osched.txt. Și, de asemenea, am văzut o creștere a ratei de citire în timpul operațiunilor mixte (multe scrieri).
„256” > /sys/block/sdc/queue/nr_requests
Numărul de solicitări I/O din buffer înainte ca acestea să fie transmise planificatorului. Dimensiunea cozii interne a unor controlere (queue_depth) este mai mare decât nr_requests ale programatorului I/O, astfel încât planificatorul I/O are șanse mici de a prioritiza și fuziona în mod corespunzător cererile. Pentru programatoarele de termen limită și CFQ, este mai bine când nr_requests este de 2 ori coada internă a controlerului. Îmbinarea și reordonarea solicitărilor ajută planificatorul să fie mai receptiv în cazul unei sarcini grele.
echo "16" > /proc/sys/vm/page-cluster
Parametrul page-cluster controlează numărul de pagini care sunt scrise în schimb la un moment dat. În exemplul de mai sus, valoarea este setată la „16” în funcție de dimensiunea benzii RAID de 64 KB. Nu are sens cu swappiness = 0, dar dacă setați swappiness la 10 sau 20, atunci folosirea acestei valori vă va ajuta când dimensiunea stripe RAID este de 64K.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc sau dev_mapper)
Setările implicite ale dispozitivului blocate pentru multe controlere RAID duc adesea la performanțe groaznice. Adăugarea opțiunii de mai sus setează citirea înainte pentru sectoarele de 4096 * 512 de octeți. Cel puțin, pentru operațiunile de streaming, viteza este crescută prin completarea memoriei cache a discului de pe cip cu citire înainte în perioada utilizată de kernel pentru a pregăti I/O. Cache-ul poate conține date care vor fi solicitate la următoarea citire. Prea preluare anticipată poate distruge I/O aleatoare pentru fișiere mari dacă consumă timp de disc potențial util sau încarcă date în afara memoriei cache.
Mai jos sunt câteva recomandări suplimentare la nivel de sistem de fișiere. Dar încă nu au fost testate. Asigurați-vă că sistemul dvs. de fișiere cunoaște dimensiunea benzii și numărul de discuri din matrice. De exemplu, aceasta este o matrice stripe raid5 de 64K de șase discuri (de fapt cinci, deoarece un disc este folosit pentru paritate). Aceste recomandări se bazează pe ipoteze teoretice și sunt compilate din diverse bloguri/articole de către experții 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))Pentru fișiere mari, luați în considerare creșterea dimensiunilor dungilor enumerate mai sus.
ATENȚIE! Tot ceea ce este descris mai sus este extrem de subiectiv pentru unele tipuri de aplicații. Acest articol nu garantează nicio îmbunătățire fără testarea prealabilă de către utilizator a aplicațiilor asociate. Ar trebui utilizat numai dacă este necesar pentru a îmbunătăți capacitatea generală de răspuns a sistemului sau dacă rezolvă problemele curente.
Materiale suplimentare:
Citeşte mai mult
Sursa: www.habr.com