În acest articol, vom discuta despre contoarele de performanță a memoriei RAM în vSphere.
Se pare că situația cu memoria este mai clară decât cu procesorul: dacă apar probleme de performanță pe VM, este greu să nu le observi. Dar, odată ce acestea apar, este mult mai complicat să le rezolvi. Să le abordăm pe rând.
Puțină teorie
Memoria RAM a mașinilor virtuale provine din memoria serverelor pe care rulează VM-urile. Este destul de evident :). Dacă serverul nu are suficientă memorie RAM pentru toate solicitările, ESXi începe să aplice tehnici de optimizare a consumului de memorie (memory reclamation techniques). În caz contrar, sistemele de operare ale VM-urilor ar cădea cu erori de acces la RAM.
Ce tehnici să aplice ESXi depinde de gradul de ocupare a memoriei RAM:
Starea memoriei
Limită
Acțiuni
Ridicat
400% din minFree
După atingerea limitei superioare, paginile mari de memorie sunt împărțite în pagini mici (TPS funcționează în modul standard).
Clear
100% din minFree
Paginile mari de memorie sunt împărțite în pagini mici, TPS funcționează forțat.
Moale
64% din minFree
TPS + Balloon
Dur
32% din minFree
TPS + Compresie + Swap
Low
16% din minFree
Compresie + Swap + Blocare
minFree este memoria RAM necesară pentru funcționarea hipervizorului.
Până la ESXi 4.1 inclusiv, minFree era implicit un procent fix — 6% din volumul de memorie RAM a serverului (procentul putea fi schimbat prin opțiunea Mem.MinFreePct pe ESXi). În versiunile mai recente, din cauza creșterii dimensiunii memoriei serverelor, minFree a început să fie calculat în funcție de volumul memoriei gazdă, și nu ca o valoare procentuală fixă.
Valoarea minFree (implicit) este calculată astfel:
Procentajul 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 RAM, valoarea MinFree va fi:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Valoarea efectivă poate varia cu câteva sute de MB, în funcție de server și de memoria RAM.
Procentajul de memorie rezervat pentru minFree
Interval de memorie
Valoarea 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 medii productive, se poate considera că singurul stadiu normal este High. Pentru mediile de testare și dezvoltare, stările Clear/Soft pot fi acceptabile. Dacă mai puțin de 64% din memorie este disponibilă pe gazdă, atunci mașinile virtuale care rulează pe aceasta vor avea cu siguranță probleme de performanță.
În fiecare stare se aplică tehnici specifice de recuperare a memoriei, începând cu TPS, care influențează practic deloc performanța mașinilor virtuale, și ajungând până la Swapping. Voi explica acestea în detaliu.
Transparent Page Sharing (TPS). TPS este, pe scurt, deduplicarea paginilor de memorie RAM ale mașinilor virtuale de pe server.
ESXi caută pagini identice de memorie RAM ale mașinilor virtuale, calculând și comparând suma hash a paginilor, și șterge duplicatele, înlocuindu-le cu referințe la aceeași pagină în memoria fizică a serverului. Ca urmare, consumul de memorie fizică scade și se poate obține o anumită reaprovizionare a memoriei practic fără scăderea performanței.
Acest mecanism funcționează doar pentru paginile de memorie de dimensiune 4 KB (pagine mici). Hypervisorul nu încearcă nici măcar să deduplicate paginile de dimensiune 2 MB (pagine mari): șansa de a găsi pagini identice de această dimensiune nu este mare.
În mod implicit, ESXi alocă memorie paginilor mari. Fragmentarea paginilor mari în pagini mici începe la atingerea pragului stării High și se desfășoară forțat atunci când se atinge starea Clear (vezi tabelul stărilor hypervisor-ului).
Dacă doriți ca TPS să înceapă să funcționeze fără a aștepta completarea memoriei gazdei, în Opțiuni avansate ESXi trebuie să setați valoarea “Mem.AllocGuestLargePage” la 0 (implicit 1). Atunci alocarea paginilor mari de memorie pentru mașinile virtuale va fi dezactivată.
Din decembrie 2014, în toate versiunile ESXi, TPS între VM-uri este dezactivat în mod implicit, deoarece s-a descoperit o vulnerabilitate, care teoretic permitea accesul dintr-o VM la memoria unei alte VM. Detaliile sunt aici. Informații despre implementarea practică a exploatării vulnerabilității TPS nu am întâlnit.
Politica TPS este controlată prin opțiunea avansată “Mem.ShareForceSalting” pe ESXi:
0 — TPS între VM-uri. TPS funcționează pentru paginile diferitelor VM-uri;
1 – TPS pentru VM-uri cu același valoare “sched.mem.pshare.salt” în VMX;
2 (implicit) – TPS intra-VM. TPS funcționează pentru paginile din interiorul VM-ului.
Este sigur că are sens să dezactivați paginile mari și să activați Inter-VM TPS pe standurile de testare. De asemenea, aceasta poate fi utilizată pentru standuri cu un număr mare de VM-uri similare. De exemplu, pe standurile VDI, economiile de memorie fizică pot ajunge la zeci de procente.
Memory Ballooning. Ballooning-ul nu mai este o tehnică atât de inofensivă și transparentă pentru sistemul de operare al VM-ului, precum TPS. Dar, cu o aplicare corectă, se poate trăi și chiar lucra cu Ballooning.
Împreună cu VMware Tools, pe VM se instalează un driver special, numit Balloon Driver (sau vmmemctl). Când hipervizorul începe să nu mai aibă suficientă memorie fizică și trece în starea Soft, ESXi cere VM-ului să returneze memoria RAM neutilizată prin acest Balloon Driver. Driverul, la rândul său, funcționează la nivelul sistemului de operare și solicită memorie liberă de la acesta. Hipervizorul vede ce pagini de memorie fizică a ocupat Balloon Driver-ul, ia memoria de la mașina virtuală și o returnează gazdei. Nu apar probleme cu funcționarea sistemului de operare, deoarece la nivelul OS memoria este ocupată de Balloon Driver. Implicit, Balloon Driver-ul poate lua până la 65% din memoria VM-ului.
Dacă VMware Tools nu sunt instalate pe VM sau Ballooning-ul este dezactivat (nu recomand, dar există :), hipervizorul trece imediat la tehnici mai dure de recuperare a memoriei. Concluzie: asigurați-vă că VMware Tools sunt instalate pe VM.
Funcționarea Balloon Driver-ului poate fi verificată din OS prin VMware Tools..
Memory Compression. Această tehnică este utilizată atunci când ESXi ajunge în starea Hard. Așa cum sugerează numele, ESXi încearcă să comprime o pagină de 4 Kbyte de memorie RAM la 2 Kbyte și, astfel, să elibereze puțin spațiu în memoria fizică a serverului. Această tehnică crește semnificativ timpul de acces la conținutul paginilor de memorie RAM ale VM-ului, deoarece pagina trebuie să fie dezvoltată anterior. Uneori, nu toate paginile pot fi comprimate, iar procesul în sine durează ceva timp. Prin urmare, această tehnică nu este foarte eficientă în practică.
Memory Swapping. După o scurtă fază de Memory Compression, ESXi trece practic inevitabil (dacă VM-urile nu au fost mutate pe alte gazde sau nu au fost oprite) la Swapping. Și dacă a rămas foarte puțină memorie (starea Low), atunci hipervizorul încetează să mai aloce VM-ului pagini de memorie, ceea ce poate provoca probleme în sistemele de operare gazdă ale VM-ului.
Iată cum funcționează Swapping. Când se pornește o mașină virtuală, se creează un fișier cu extensia .vswp. Dimensiunea acestuia este egală cu memoria RAM nerezervată a MV: aceasta reprezintă diferența dintre memoria configurată și cea rezervată. Atunci când se utilizează Swapping, 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. Evident, această așa-numită „memorie operativă” este cu câteva ordine de mărime mai lentă decât cea reală, chiar dacă .vswp se află pe un stocare rapidă.
Spre deosebire de Ballooning, când MV-ului i se iau pagini neutilizate, la Swapping paginile care sunt active în sistemul de operare sau în aplicațiile din MV pot fi mutate pe disc. Drept urmare, performanța MV-ului scade, ajungând până la blocaje. MV-ul funcționează formal și cel puțin poate fi oprit corect din sistemul de operare. Dacă aveți răbdare😉
Dacă MV-urile au ajuns în Swap, aceasta este o situație anormală pe care ar trebui să o evitați cât mai mult posibil.
Principalele metrici de performanță a memoriei mașinii virtuale
Iată-ne ajungând la esențial. Pentru monitorizarea stării memoriei în MV, există următoarele metrici:
Activ — arată volumul de memorie RAM (Kbyte) la care MV-ul a avut acces în perioada de măsurare anterioară.
Utilizare — același lucru ca Activ, dar în procente din memoria RAM configurată a MV-ului. Este calculat folosind următoarea formulă: activ ÷ dimensiunea memoriei virtuale configurate a mașinii.
O Utilizare și Activă ridicate nu sunt neapărat un indicator al problemelor de performanță ale MV-ului. Dacă MV-ul utilizează agresiv memoria (de cel puțin, are acces la aceasta), nu înseamnă că îi lipsește. Mai degrabă, este un motiv să verificați ce se întâmplă în sistemul de operare.
Există o Alarmă standard pentru Utilizarea Memoriei pentru MV:
Partajat — volumul de memorie RAM al MV-ului, deduplicat folosind TPS (în cadrul MV-ului sau între MV-uri).
Acordat — volumul de memorie fizică a gazdei (Kbyte), care a fost alocat MV-ului. Include Shared.
Consumpt (Acordat — Shared) — volumul de memorie fizică (Kbyte) consumat de MV de la gazdă. Nu include Shared.
Dacă o parte din memoria MV-ului este alocată nu din memoria fizică a gazdei, ci din swap-file sau memoria este luată de la MV prin Balloon Driver, acest volum nu este inclus în Acordat și Consumpt.
Valorile mari pentru Granted și Consumed sunt perfect normale. Sistemul de operare absoarbe treptat memorie de la hypervisor și nu o returnează. În timp, pentru o VM activă, valorile acestor contoare se apropie de cantitatea de memorie configurată și rămân acolo.
Zero — cantitatea de memorie RAM a VM-ului (KB) care conține zerouri. Această memorie este considerată liberă de hypervisor și poate fi alocată altor mașini virtuale. După ce sistemul de operare gazdă a scris ceva în memoria zero, aceasta trece în Consumed și nu mai revine.
Reserved Overhead — cantitatea de memorie RAM a VM-ului (KB) rezervată de hypervisor pentru funcționarea VM-ului. Acesta este un volum mic, dar trebuie să fie disponibil pe gazdă, altfel VM-ul nu va porni.
Balloon — cantitatea de memorie RAM (KB) extrasă de la VM prin intermediul Balloon Driver.
Compressed — cantitatea de memorie RAM (KB) care a reușit să fie comprimată.
Swapped — cantitatea de memorie RAM (KB) care, din lipsă de memorie fizică pe server, a fost mutată pe disc.
Balloon și ceilalți indicatori ai tehnicilor de recuperare a memoriei sunt egali cu zero.
Așa arată un grafic cu contoarele Memory pentru o VM care funcționează normal cu 150 GB de memorie RAM.
În graficul de mai jos, VM-ul are probleme evidente. Sub grafic se poate observa că pentru această VM au fost utilizate toate tehnicile descrise pentru gestionarea memoriei. Balloon pentru această VM este mult mai mare decât Consumed. De fapt, VM-ul este mai degrabă mort decât viu.
ESXTOP
Așa cum se întâmplă și cu CPU, dacă dorim să evaluăm rapid situația pe gazdă, precum și dinamica acesteia la intervale de până la 2 secunde, ar trebui să folosim ESXTOP.
Ecranul ESXTOP pentru Memory se deschide cu tasta „m” și arată astfel (câmpurile selectate: B,D,H,J,K,L,O):
Parametrii următori ne vor interesa:
Mem overcommit avg — valoarea medie a supraîncărcării memoriei pe gazdă în ultimele 1, 5 și 15 minute. Dacă este mai mare de zero, este un motiv să verificăm ce se întâmplă, dar nu este întotdeauna un indicator al existenței problemelor.
În rândurile PMEM/MB și VMKMEM/MB — informații despre memoria fizică a serverului și memoria disponibilă VMkernel. Din detalii, aici putem observa valoarea minfree (în MB), starea gazdei în ceea ce privește memoria (în cazul nostru, high).
În rândul NUMA/MB se poate observa distribuția memoriei RAM pe nodurile NUMA (soclu). În acest exemplu, distribuția este inegală, ceea ce nu este foarte bine.
Următorul este un rezumat general al statisticilor serverului privind tehnicile de recuperare a memoriei:
PSHARE/MB — aceasta este statistica TPS;
SWAP/MB — statistică utilizare Swap;
ZIP/MB — statistică pentru comprimarea paginilor de memorie;
MEMCTL/MB — statistică utilizare Balloon Driver.
Pentru fiecare VM, ne-ar putea interesa următoarele informații. Am ascuns numele VM-urilor pentru a nu confunda audiența :). Dacă metrica ESXTOP este similară cu contorul din vSphere, ofer contorul corespunzător.
MEMSZ — volumul de memorie configurat pe VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
GRANT — Grantat în MB.
TCHD — Activ în MB.
MCTL? — Dacă Balloon Driver este instalat pe VM.
MCTLSZ — Balloon în MB.
MCTLGT — volumul de memorie RAM (MB) pe care ESXi vrea să-l recupereze de la VM prin Balloon Driver (Memctl Target).
MCTLMAX — volumul maxim de memorie RAM (MB) pe care ESXi poate să-l recupereze de la VM prin Balloon Driver.
SWCUR — volumul curent de memorie RAM (MB) alocat VM-ului din fișierul Swap.
SWGT — volumul de memorie RAM (MB) pe care ESXi dorește să-l aloce VM-ului din fișierul Swap (Swap Target).
De asemenea, prin ESXTOP se poate vizualiza informații mai detaliate despre topologia NUMA a VM-ului. Pentru aceasta, trebuie selectate câmpurile D,G:
NHN – nodurile NUMA pe care se află VM-ul. Aici se pot observa imediat VM-uri mari care nu încap pe un singur nod NUMA.
NRMEM – câți megabaiți de memorie ia VM-ul de pe un nod NUMA îndepărtat.
NLMEM – câți megabaiți de memorie ia VM-ul de pe un nod NUMA local.
N%L – procentul de memorie VM pe nodul NUMA local (dacă este mai mic de 80% — pot apărea probleme de performanță).
Memorie pe hypervizor
Dacă contoarele CPU pe hypervizor de obicei nu prezintă un interes deosebit, în cazul memoriei situația este inversă. Un nivel ridicat de utilizare a memoriei pe VM nu înseamnă întotdeauna că există o problemă de performanță, dar un nivel ridicat de utilizare a memoriei pe hypervizor activează tehnicile de gestionare a memoriei și provoacă probleme de performanță ale VM-ului. Este important să monitorizăm alertele de utilizare a memoriei gazdei și să evităm ca VM-urile să ajungă în Swap.
Unswap
Dacă VM-ul a ajuns în Swap, performanța sa scade semnificativ. Urmele Ballooning-ului și comprimării dispar rapid după ce apare memorie RAM liberă pe host, dar întoarcerea din Swap în memoria RAM a serverului nu se face deloc cu repeziciune.
Până la versiunea ESXi 6.0, singura modalitate de încredere și rapidă de a scoate VM-urile din Swap era repornirea (mai precis, oprirea/ c și apoi activarea contului). Începând cu ESXi 6.0, a apărut o metodă, deși nu tocmai oficială, dar funcțională și de încredere de a scoate VM-urile din Swap. La una dintre conferințe, am reușit să discut cu unul dintre inginerii VMware care se ocupă de CPU Scheduler. El a confirmat că această metodă este destul de funcțională și sigură. Din experiența noastră, nu am avut probleme cu aceasta.
Comenzile propriu-zise pentru scoaterea VM-urilor din Swap Duncan Epping. Nu voi repeta descrierea detaliată, voi da doar un exemplu de utilizare. După cum se vede în captura de ecran, după un timp, după executarea comenzii specifice, Swap-ul de pe VM dispare.
Sfaturi pentru gestionarea memoriei RAM pe ESXi
În cele din urmă, voi oferi câteva sfaturi care vă vor ajuta să evitați problemele de performanță ale VM-ului din cauza memoriei RAM:
- Evitați overcommitment-ul memoriei RAM în clusterele productive. Este recomandat să aveți întotdeauna ~20-30% din memorie liberă în cluster, astfel încât DRS (și administratorul) să aibă spațiu pentru manevră și, în timpul migrației VM-uri, acestea să nu ajungă în Swap. De asemenea, nu uitați de rezervele pentru toleranța la defectiuni. Este neplăcut când, în cazul unui server căzut și la repornirea VM-ului prin HA, o parte din mașini ajung să meargă în Swap.
- În infrastructurile cu un grad ridicat de consolidare, încercați SĂ NU creați VM-uri cu memorie mai mare de jumătate din memoria host-ului. Acest lucru va ajuta din nou DRS să aloce fără probleme mașinile virtuale pe serverele clusterului. Această regulă, desigur, nu este universală :).
- Monitorizați Alarma de Utilizare a Memorii Host.
- Nu uitați să instalați VMware Tools pe VM-uri și să nu dezactivați Ballooning-ul.
- Considerați activarea Inter-VM TPS și dezactivarea Large Pages în medii cu VDI și medii de testare.
- Dacă VM-ul întâmpină probleme de performanță, verificați dacă folosește memorie de pe un nod NUMA îndepărtat.
- Scoateți VM-urile din Swap cât mai repede posibil! Pe lângă toate acestea, dacă un VM se află în Swap, din motive evidente, este afectat spațiul de stocare.
Asta e tot despre memoria RAM pentru mine. Mai jos sunt articole pe acest subiect pentru cei care vor să se aprofundeze în detalii. Următorul articol va fi dedicat stocării.
Linkuri utile
Sursa: habr.com
