În acest articol, vom vorbi despre contoarele de performanță ale memoriei cu acces aleatoriu (RAM) în vSphere.
Se pare că cu memoria totul este mai clar decât cu procesorul: dacă un VM are probleme de performanță, e greu să nu le observi. Dar dacă apar, este mult mai dificil să le faci față. Dar mai întâi lucrurile.
Un pic de teorie
Memoria RAM a mașinilor virtuale este preluată din memoria serverului pe care rulează mașinile virtuale. Este destul de evident :). Dacă RAM-ul serverului nu este suficient pentru toată lumea, ESXi începe să folosească tehnici de recuperare a memoriei pentru a optimiza consumul de RAM. În caz contrar, sistemele de operare VM s-ar bloca cu erori de acces la RAM.
Ce tehnici pentru a utiliza ESXi decide în funcție de încărcarea RAM:
Starea memoriei
frontieră
Activitate
Înalt
400% din minGratuit
După atingerea limitei superioare, paginile mari de memorie sunt împărțite în altele mici (TPS funcționează în modul standard).
clar
100% din minGratuit
Paginile mari de memorie sunt împărțite în altele mici, TPS este forțat să funcționeze.
Moale
64% din minGratuit
TPS + balon
Greu
32% din minGratuit
TPS + Comprimare + Schimbare
Jos
16% din minGratuit
Comprimați + Schimbați + Blocați
minFree este memoria RAM necesară pentru ca hipervizorul să funcționeze.
Înainte de ESXi 4.1 inclusiv, minFree era fixat în mod implicit - 6% din RAM-ul serverului (procentul putea fi modificat prin opțiunea Mem.MinFreePct pe ESXi). În versiunile ulterioare, din cauza creșterii dimensiunilor memoriei pe servere, minFree a început să fie calculat pe baza cantității de memorie gazdă, și nu ca procent fix.
Valoarea minFree (implicit) este calculată după cum urmează:
Procentul de memorie rezervat pentru minFree
Interval de memorie
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Memoria rămasă
De exemplu, pentru un server cu 128 GB de RAM, valoarea MinFree ar fi:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Valoarea reală poate diferi cu câteva sute de MB, depinde de server și RAM.
Procentul de memorie rezervat pentru minFree
Interval de memorie
Valoare pentru 128 GB
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Memoria rămasă (100 GB)
1024 MB
De obicei, pentru standurile productive, doar starea Înaltă poate fi considerată normală. Pentru bancurile de testare și dezvoltare, stările Clear/Soft pot fi acceptabile. Dacă memoria RAM de pe gazdă este mai mică de 64% MinFree, atunci VM-urile care rulează pe ea au cu siguranță probleme de performanță.
În fiecare stare se aplică anumite tehnici de recuperare a memoriei, începând cu TPS, care practic nu afectează performanța VM, și terminând cu Swapping. Vă voi spune mai multe despre ele.
Partajare transparentă a paginii (TPS). TPS este, în linii mari, deduplicarea paginilor de memorie a mașinii virtuale pe un server.
ESXi caută pagini identice ale RAM-ului mașinii virtuale, numărând și comparând suma hash a paginilor și elimină paginile duplicate, înlocuindu-le cu link-uri către aceeași pagină din memoria fizică a serverului. Ca rezultat, consumul de memorie fizică este redus și se poate obține o supraabonare a memoriei cu o degradare mică sau deloc a performanței.
Acest mecanism funcționează numai pentru pagini de memorie de 4 KB (pagini mici). Hipervizorul nici măcar nu încearcă să dedupe pagini de 2 MB (pagini mari): șansa de a găsi pagini identice de această dimensiune nu este mare.
În mod implicit, ESXi alocă memorie paginilor mari. Împărțirea paginilor mari în pagini mici începe când este atins pragul de stare înalt și este forțată când este atinsă starea de ștergere (consultați tabelul de stare a hipervizorului).
Dacă doriți ca TPS să înceapă să funcționeze fără să așteptați ca memoria RAM gazdă să se umple, în Opțiuni avansate ESXi trebuie să setați valoarea „Mem.AllocGuestLargePage” la 0 (implicit 1). Apoi, alocarea paginilor mari de memorie pentru mașinile virtuale va fi dezactivată.
Din decembrie 2014, în toate versiunile ESXi, TPS între VM a fost dezactivat în mod implicit, deoarece s-a găsit o vulnerabilitate care permite teoretic accesul de la o VM la RAM-ul altei VM. Detalii aici. Nu am întâlnit informații despre implementarea practică a exploatării vulnerabilității TPS.
Politica TPS controlată prin opțiune avansată „Mem.ShareForceSalting” pe ESXi:
0 - Inter-VM TPS. TPS funcționează pentru pagini de diferite VM;
1 – TPS pentru VM cu aceeași valoare „sched.mem.pshare.salt” în VMX;
2 (implicit) - TPS intra-VM. TPS funcționează pentru pagini din interiorul VM.
Cu siguranță are sens să dezactivați paginile mari și să activați Inter-VM TPS pe bancurile de testare. Poate fi folosit și pentru standuri cu un număr mare de același tip de VM. De exemplu, pe standurile cu VDI, economiile în memoria fizică pot ajunge la zeci de procente.
balonarea memoriei. Balonarea nu mai este o tehnică atât de inofensivă și transparentă pentru sistemul de operare VM precum TPS. Dar cu o aplicare adecvată, puteți trăi și chiar lucra cu Ballooning.
Împreună cu Vmware Tools, pe VM este instalat un driver special numit Balloon Driver (alias vmmemctl). Când hipervizorul începe să epuizeze memoria fizică și intră în starea Soft, ESXi solicită VM-ului să recupereze RAM neutilizată prin acest driver de balon. Driverul, la rândul său, funcționează la nivel de sistem de operare și solicită memorie liberă de la acesta. Hipervizorul vede ce pagini de memorie fizică a ocupat driverul Balloon, ia memoria din mașina virtuală și o returnează gazdei. Nu există probleme cu funcționarea sistemului de operare, deoarece la nivelul sistemului de operare memoria este ocupată de driverul Balloon. În mod implicit, Balloon Driver poate ocupa până la 65% din memoria VM.
Dacă VMware Tools nu sunt instalate pe VM sau Ballooning este dezactivat (nu recomand, dar există :), hypervisorul trece imediat la tehnici mai stricte de eliminare a memoriei. Concluzie: asigurați-vă că VMware Tools este pe VM.
Funcționarea Balloon Driver poate fi verificată din sistemul de operare prin VMware Tools.
compresia memoriei. Această tehnică este utilizată atunci când ESXi ajunge la starea Hard. După cum sugerează și numele, ESXi încearcă să micșoreze o pagină de 4 KB de RAM la 2 KB și astfel să elibereze spațiu în memoria fizică a serverului. Această tehnică crește semnificativ timpul de acces la conținutul paginilor RAM VM, deoarece pagina trebuie mai întâi decomprimată. Uneori nu toate paginile pot fi comprimate, iar procesul în sine durează ceva timp. Prin urmare, această tehnică nu este foarte eficientă în practică.
schimbarea memoriei. După o scurtă fază de compresie a memoriei, ESXi aproape inevitabil (dacă VM-urile nu au plecat pentru alte gazde sau nu s-au oprit) va trece la Schimbare. Și dacă rămâne foarte puțină memorie (stare scăzută), atunci și hypervisorul încetează alocarea paginilor de memorie către VM, ceea ce poate cauza probleme în sistemul de operare invitat al VM.
Iată cum funcționează Schimbarea. Când porniți o mașină virtuală, este creat pentru aceasta un fișier cu extensia .vswp. Este egală ca dimensiune cu RAM nerezervată a VM: este diferența dintre memoria configurată și cea rezervată. Când se execută Schimbarea, ESXi descarcă paginile de memorie ale mașinii virtuale în acest fișier și începe să lucreze cu acesta în loc de memoria fizică a serverului. Desigur, o astfel de memorie „operativă” este cu câteva ordine de mărime mai lentă decât cea reală, chiar dacă .vswp se află pe stocarea rapidă.
Spre deosebire de Ballooning, atunci când paginile neutilizate sunt preluate din VM, cu Swapping, paginile care sunt utilizate în mod activ de sistemul de operare sau aplicațiile din interiorul VM se pot muta pe disc. Ca rezultat, performanța VM scade până la punctul de înghețare. VM funcționează în mod oficial și cel puțin poate fi dezactivat corespunzător din sistemul de operare. Daca ai rabdare 😉
Dacă VM-urile au trecut la Swap, aceasta este o situație anormală, care este cel mai bine evitată dacă este posibil.
Contoare cheie de performanță a memoriei VM
Așa că am ajuns la punctul principal. Pentru a monitoriza starea memoriei în VM, există următoarele contoare:
Activ — arată cantitatea de RAM (KB) la care a avut acces VM în perioada anterioară de măsurare.
Folosire - la fel ca Active, dar ca procent din RAM configurată a VM-ului. Calculat folosind următoarea formulă: activ ÷ dimensiunea memoriei configurată mașină virtuală.
Utilizare ridicată și, respectiv, activ, nu sunt întotdeauna un indicator al problemelor de performanță VM. Dacă VM-ul folosește în mod agresiv memoria (cel puțin are acces la ea), aceasta nu înseamnă că nu există suficientă memorie. Mai degrabă, este o ocazie de a vedea ce se întâmplă în sistemul de operare.
Există o alarmă standard de utilizare a memoriei pentru VM:
Shared - cantitatea de RAM VM deduplicată folosind TPS (în interiorul VM sau între VM).
acordat - cantitatea de memorie fizică a gazdei (KB) care a fost dată VM-ului. Include Partajat.
consumate (Acordat - Partajat) - cantitatea de memorie fizică (KB) pe care VM o consumă de la gazdă. Nu include Partajat.
Dacă o parte din memoria VM este dată nu din memoria fizică a gazdei, ci din fișierul swap, sau memoria este preluată din VM prin driverul Balloon, această sumă nu este luată în considerare în Acordat și Consumat.
Valorile ridicate acordate și consumate sunt perfect normale. Sistemul de operare preia treptat memorie de la hypervisor și nu o dă înapoi. De-a lungul timpului, într-o VM care rulează activ, valorile acestor contoare se apropie de cantitatea de memorie configurată și rămân acolo.
Zero — cantitatea de RAM VM (KB), care conține zerouri. O astfel de memorie este considerată liberă de către hypervisor și poate fi dată altor mașini virtuale. După ce sistemul de operare invitat a scris ceva în memoria zero, acesta intră în Consumed și nu se întoarce înapoi.
Regim rezervat — cantitatea de RAM VM, (KB) rezervată de hypervisor pentru operarea VM. Aceasta este o cantitate mică, dar trebuie să fie disponibilă pe gazdă, altfel VM-ul nu va porni.
Balon — cantitatea de RAM (KB) confiscată de la VM folosind driverul Balloon.
comprimat - cantitatea de RAM (KB) care a fost comprimată.
interschimba - cantitatea de RAM (KB) care, din cauza lipsei de memorie fizică de pe server, a fost mutată pe disc.
Contoarele de baloane și alte tehnici de recuperare a memoriei sunt zero.
Așa arată graficul cu contoare de memorie pentru o VM care funcționează normal cu 150 GB de RAM.
În graficul de mai jos, VM-ul are probleme evidente. Sub grafic, puteți vedea că pentru acest VM au fost utilizate toate tehnicile descrise pentru lucrul cu RAM. Balonul pentru acest VM este mult mai mare decât Consumed. De fapt, VM-ul este mai mult mort decât viu.
ESXTOP
Ca și în cazul procesorului, dacă dorim să evaluăm rapid situația pe gazdă, precum și dinamica acesteia cu un interval de până la 2 secunde, ar trebui să folosim ESXTOP.
Ecranul ESXTOP de către Memory este apelat cu tasta „m” și arată astfel (câmpurile B, D, H, J, K, L, O sunt selectate):
Următorii parametri ne vor interesa:
Mem overcommit avg - valoarea medie a supraabonamentului de memorie pe gazdă pentru 1, 5 și 15 minute. Dacă este peste zero, atunci aceasta este o ocazie de a vedea ce se întâmplă, dar nu întotdeauna un indicator al problemelor.
În rânduri PMEM/MB и VMKMEM/MB - informații despre memoria fizică a serverului și memoria disponibilă pentru VMkernel. Din cele interesante de aici puteți vedea valoarea minfree (în MB), starea gazdei în memorie (în cazul nostru, mare).
In linie NUMA/MB puteți vedea distribuția memoriei RAM după nodurile (socket-uri) NUMA. În acest exemplu, distribuția este neuniformă, ceea ce, în principiu, nu este foarte bun.
Următoarele sunt statistici generale ale serverului privind tehnicile de recuperare a memoriei:
PSHARE/MB sunt statistici TPS;
SWAP/MB — Schimbați statistici de utilizare;
ZIP/MB — statistici de compresie a paginii de memorie;
MEMCTL/MB — Statistici de utilizare a driverului balonului.
Pentru VM-urile individuale, este posibil să fim interesați de următoarele informații. Am ascuns numele VM pentru a nu deruta publicul :). Dacă metrica ESXTOP este similară cu contorul din vSphere, dau contorul corespunzător.
MEMSZ — cantitatea de memorie configurată pe VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + neatins.
GRANT — Acordat lui MB.
TCHD — Activ în MB.
MCTL? - dacă Balloon Driver este instalat pe VM.
MCTLSZ — Balon către MB.
MCTLGT — cantitatea de RAM (MB) pe care ESXi dorește să o ia de la VM prin intermediul driverului Balloon (țintă Memctl).
MCTLMAX - cantitatea maximă de RAM (MB) pe care ESXi o poate lua de la VM prin driverul Balloon.
SWCUR — cantitatea actuală de RAM (MB) alocată VM-ului din fișierul Swap.
S.W.G.T. - cantitatea de RAM (MB) pe care ESXi dorește să o acorde VM-ului din fișierul Swap (Swap Target).
De asemenea, prin ESXTOP, puteți vedea informații mai detaliate despre topologia NUMA a VM. Pentru a face acest lucru, selectați câmpurile D, G:
MIC – Nodurile NUMA pe care se află VM-ul. Aici puteți observa imediat vm largi, care nu se potrivesc pe un singur nod NUMA.
NRMEM - câți megaocteți de memorie ia VM de la nodul NUMA la distanță.
NLMEM - câți megaocteți de memorie ia VM-ul de la nodul local NUMA.
N%L – procentul de memorie VM pe nodul local NUMA (dacă este mai mic de 80%, pot apărea probleme de performanță).
Memorie pe hypervisor
Dacă contoarele CPU pentru hypervisor nu prezintă de obicei un interes deosebit, atunci situația este inversată cu memoria. Utilizarea ridicată a memoriei pe un VM nu indică întotdeauna o problemă de performanță, dar utilizarea ridicată a memoriei pe un hypervisor declanșează tehnici de gestionare a memoriei și cauzează probleme de performanță în VM. Alarmele de utilizare a memoriei gazdei trebuie monitorizate pentru a preveni intrarea VM-ului în Swap.
Anulați schimbul
Dacă un VM este în Swap, performanța sa este mult redusă. Urmele de balonare și compresie dispar rapid după ce RAM liberă apare pe gazdă, dar mașina virtuală nu se grăbește să revină de la Swap la RAM-ul serverului.
Înainte de ESXi 6.0, singura modalitate fiabilă și rapidă de a scoate o VM din Swap era repornirea (pentru a fi mai precis, oprirea/pornirea containerului). Începând cu ESXi 6.0, deși nu chiar oficial, a apărut o modalitate funcțională și fiabilă de a elimina o VM din Swap. La una dintre conferințe, am putut vorbi cu unul dintre inginerii VMware responsabili cu CPU Scheduler. El a confirmat că metoda este destul de funcțională și sigură. Din experiența noastră, nici nu au fost probleme cu el.
Comenzile reale pentru eliminarea VM-ului din Swap Duncan Epping. Nu voi repeta o descriere detaliată, ci doar da un exemplu de utilizare a acesteia. După cum puteți vedea în captură de ecran, la ceva timp după executarea comenzilor specificate, Swap dispare pe VM.
Sfaturi de gestionare a memoriei ESXi
În cele din urmă, iată câteva sfaturi care vă vor ajuta să evitați problemele cu performanța VM din cauza RAM:
- Evitați supraabonamentul de memorie în clustere productive. Este de dorit să aveți întotdeauna ~20-30% memorie liberă în cluster, astfel încât DRS (și administratorul) să aibă spațiu de manevră, iar VM-urile să nu intre în Swap în timpul migrării. De asemenea, nu uitați de marja de toleranță la erori. Este neplăcut când, când un server eșuează și VM-ul este repornit folosind HA, unele dintre mașini intră și în Swap.
- În infrastructurile foarte consolidate, încercați NU să creați VM-uri cu mai mult de jumătate din memoria gazdei. Acest lucru va ajuta din nou DRS să distribuie mașinile virtuale pe serverele cluster fără probleme. Această regulă, desigur, nu este universală :).
- Urmăriți alarma de utilizare a memoriei gazdei.
- Nu uitați să instalați VMware Tools pe VM și să nu dezactivați balonarea.
- Luați în considerare activarea TPS inter-VM și dezactivarea paginilor mari în mediile VDI și de testare.
- Dacă VM întâmpină probleme de performanță, verificați dacă folosește memoria de la un nod NUMA la distanță.
- Scoateți VM-ul dvs. din Swap cât mai repede posibil! Printre altele, dacă VM-ul este în Swap, din motive evidente, sistemul de stocare are de suferit.
Asta e tot pentru mine despre RAM. Mai jos este un articol conex pentru cei care doresc să sape în detalii. Următorul articol va fi dedicat storadzh.
Link-uri utile
Sursa: www.habr.com