La traducció de l'article es va preparar la vigília de l'inici del curs .
Periòdicament, aquí i allà, sorgeixen preguntes sobre les recomanacions de Gluster pel que fa a l'ajustament del nucli i si és necessari.
Aquesta necessitat rarament sorgeix. A la majoria de càrregues de treball, el nucli funciona molt bé. Encara que hi ha un inconvenient. Històricament, el nucli de Linux ha estat disposat a consumir molta memòria si se'n dona l'oportunitat, inclòs l'emmagatzematge a la memòria cau com a principal forma de millorar el rendiment.
En la majoria dels casos, això funciona bé, però amb una càrrega pesada pot provocar problemes.
Tenim molta experiència amb sistemes intensius de memòria com ara CAD, EDA i similars, que van començar a frenar-se amb una càrrega pesada. I de vegades ens trobem amb problemes a Gluster. Després d'observar detingudament l'ús de la memòria i la latència del disc durant molts dies, vam obtenir la seva sobrecàrrega, enorme iowait, errors del nucli (kernel oops), congelació, etc.
Aquest article és el resultat de molts experiments d'afinació realitzats en diverses situacions. Gràcies a aquests paràmetres, no només ha millorat la capacitat de resposta general, sinó que el clúster també s'ha estabilitzat significativament.
Quan es tracta d'ajustar la memòria, el primer que cal mirar és el subsistema de memòria virtual (VM, memòria virtual), que té un gran nombre d'opcions que poden confondre't.
vm.canvi
Paràmetre vm.swappiness determina quant utilitza el nucli l'intercanvi (intercanvi, paginació) en comparació amb la memòria RAM. També es defineix al codi font com "tendència a robar la memòria mapeada". Un alt intercanvi significa que el nucli estarà més inclinat a intercanviar pàgines assignades. Un valor d'intercanvi baix significa el contrari: el nucli farà menys pàgines des de la memòria. En altres paraules, com més gran sigui el valor vm.swappiness, més utilitzarà l'intercanvi el sistema.
No és desitjable un gran ús de l'intercanvi, ja que es carreguen i descarreguen grans blocs de dades a la memòria RAM. Molta gent argumenta que el valor d'intercanvi hauria de ser gran, però segons la meva experiència, posar-lo a "0" comporta un millor rendiment.
Podeu llegir més aquí -
Però, de nou, aquests paràmetres s'han d'aplicar amb cura i només després de provar una aplicació concreta. Per a aplicacions de reproducció en temps real amb molta càrrega, aquest paràmetre s'hauria d'establir a "0". Quan es canvia a "0", la capacitat de resposta del sistema millora.
vm.vfs_cache_pressure
Aquesta configuració controla la memòria que consumeix el nucli per a la memòria cau dels objectes de directoris i inode (dentry i inode).
Amb un valor predeterminat de 100, el nucli intentarà alliberar les memòries cau de dentry i inode de manera "justa" per a pagecache i swapcache. La disminució de vfs_cache_pressure fa que el nucli mantingui la memòria cau de dentry i inode. Quan el valor és "0", el nucli mai esborrarà la memòria cau de la dentry i l'inode a causa de la pressió de la memòria, i això pot provocar fàcilment un error de falta de memòria. L'augment de la vfs_cache_pressure per sobre de 100 fa que el nucli prioritzi el rentat de dentry i inode.
Quan utilitzen GlusterFS, molts usuaris amb grans quantitats de dades i molts fitxers petits poden utilitzar fàcilment una quantitat important de RAM al servidor a causa de la memòria cau d'inode/dentry, que pot provocar una degradació del rendiment ja que el nucli ha de processar estructures de dades en un sistema. amb 40 GB de memòria. Establir aquest valor per sobre de 100 ha ajudat a molts usuaris a aconseguir una memòria cau més justa i una capacitat de resposta millorada del nucli.
vm.dirty_background_ratio i vm.dirty_ratio
Primer paràmetre (vm.dirty_background_ratio) determina el percentatge de memòria amb pàgines brutes, després d'arribar al qual cal començar a esborrar les pàgines brutes en segon pla al disc. Fins que no s'arriba a aquest percentatge, no s'enviarà cap pàgina al disc. I quan comença el restabliment, s'executa en segon pla sense interrompre els processos en execució.
El segon paràmetre (vm.dirty_ratio) defineix el percentatge de memòria que poden ocupar les pàgines brutes abans que comenci el flash forçat. Un cop s'ha arribat a aquest llindar, tots els processos es tornen sincrònics (bloquejats) i no se'ls permet continuar fins que l'E/S que han sol·licitat s'ha completat i les dades estan al disc. Amb E/S pesades, això causa un problema perquè no hi ha memòria cau de dades i tots els processos que fan E/S estan bloquejats esperant l'E/S. Això condueix a un gran nombre de processos penjats, càrrega elevada, inestabilitat del sistema i baix rendiment.
Disminuir aquests paràmetres fa que les dades s'esborrin al disc amb més freqüència i no s'emmagatzemin a la memòria RAM. Això pot ajudar els sistemes amb una gran quantitat de memòria on és normal esborrar memòria cau de pàgines de 45-90 GB al disc, donant lloc a una gran latència per a les aplicacions frontals, reduint la capacitat de resposta i la interactivitat generals.
"1" > /proc/sys/vm/pagecache
Una memòria cau de pàgines és una memòria cau que emmagatzema les dades dels fitxers i programes executables, és a dir, es tracta de pàgines amb el contingut real dels fitxers o dispositius de bloqueig. Aquesta memòria cau s'utilitza per reduir el nombre de lectures de disc. Un valor d'"1" significa que s'utilitza l'1% de la memòria cau per a la memòria cau i que hi haurà més lectures des del disc que des de la memòria RAM. No cal canviar aquesta configuració, però si sou paranoicos sobre controlar la memòria cau de la pàgina, podeu utilitzar-la.
"data límit" > /sys/block/sdc/queue/scheduler
El planificador d'E/S és un component del nucli de Linux que gestiona les cues de lectura i escriptura. En teoria, és millor utilitzar "noop" per a un controlador RAID intel·ligent, perquè Linux no sap res sobre la geometria física del disc, de manera que és més eficient deixar que el controlador, que coneix bé la geometria del disc, processi la sol·licitud tan ràpidament com possible. Però sembla que la "data límit" millora el rendiment. Podeu llegir més sobre els planificadors a la documentació del codi font del nucli de Linux: linux/Documentation/block/*osched.txt. I també he vist un augment del rendiment de lectura durant operacions mixtes (moltes escriptures).
"256" > /sys/block/sdc/queue/nr_requests
El nombre de peticions d'E/S a la memòria intermèdia abans de passar-les al planificador. La mida de la cua interna d'alguns controladors (queue_depth) és més gran que les nr_requests del planificador d'E/S, de manera que el planificador d'E/S té poques possibilitats de prioritzar i combinar les sol·licituds correctament. Per als programadors de data límit i CFQ, és millor quan nr_requests sigui 2 vegades la cua interna del controlador. La fusió i la reordenació de les sol·licituds ajuda el planificador a ser més sensible a una càrrega pesada.
echo "16" > /proc/sys/vm/page-cluster
El paràmetre de clúster de pàgines controla el nombre de pàgines que s'escriuen a l'intercanvi alhora. A l'exemple anterior, el valor s'estableix en "16" segons la mida de la banda RAID de 64 KB. No té sentit amb swappiness = 0, però si configureu l'intercanvi a 10 o 20, utilitzar aquest valor us ajudarà quan la mida de la banda RAID sigui de 64K.
blockdev --setra 4096 /dev/<nom de desenvolupament> (-sdb, hdc o dev_mapper)
La configuració predeterminada del dispositiu de bloc per a molts controladors RAID sovint produeix un rendiment terrible. Si afegiu l'opció anterior, es configura la lectura anticipada per a sectors de 4096 * 512 bytes. Com a mínim, per a les operacions de streaming, la velocitat s'incrementa omplint la memòria cau del disc del xip amb lectura anticipada durant el període utilitzat pel nucli per preparar l'E/S. La memòria cau pot contenir dades que es demanaran a la propera lectura. Massa recuperació prèvia pot matar l'E/S aleatòria per a fitxers grans si consumeix temps de disc potencialment útil o carrega dades fora de la memòria cau.
A continuació es mostren algunes recomanacions més a nivell de sistema de fitxers. Però encara no s'han provat. Assegureu-vos que el vostre sistema de fitxers conegui la mida de la banda i el nombre de discs de la matriu. Per exemple, que es tracta d'una matriu stripe raid5 de 64K de sis discs (en realitat cinc, perquè s'utilitza un disc per a la paritat). Aquestes recomanacions es basen en supòsits teòrics i es recullen a partir de diversos blocs/articles per experts en 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))Per a fitxers grans, considereu augmentar les mides de les ratlles que s'indiquen més amunt.
ADVERTÈNCIA! Tot el que s'ha descrit anteriorment és molt subjectiu per a alguns tipus d'aplicacions. Aquest article no garanteix cap millora sense proves prèvies d'aplicacions relacionades amb l'usuari. Només s'ha d'utilitzar si és necessari per millorar la capacitat de resposta global del sistema, o si resol problemes actuals.
Materials addicionals:
Llegeix més
Font: www.habr.com