{"id":35292,"date":"2019-10-31T22:03:28","date_gmt":"2019-10-31T19:03:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory\/"},"modified":"2019-10-31T22:03:28","modified_gmt":"2019-10-31T19:03:28","slug":"analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","title":{"rendered":"Analiza performan\u021bei VM-urilor \u00een VMware vSphere. Partea 2: Memorie","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Analiza
\n
\nPartea 1. Despre CPU<\/a><\/noindex><\/p>\n

\u00cen acest articol, vom discuta despre contoarele de performan\u021b\u0103 a memoriei RAM \u00een vSphere.
\nSe pare c\u0103 situa\u021bia cu memoria este mai clar\u0103 dec\u00e2t cu procesorul: dac\u0103 apar probleme de performan\u021b\u0103 pe VM, este greu s\u0103 nu le observi. Dar, odat\u0103 ce acestea apar, este mult mai complicat s\u0103 le rezolvi. S\u0103 le abord\u0103m pe r\u00e2nd. <\/a><\/noindex><\/p>\n

Pu\u021bin\u0103 teorie<\/h3>\n

\nMemoria RAM a ma\u0219inilor virtuale provine din memoria serverelor pe care ruleaz\u0103 VM-urile. Este destul de evident :). Dac\u0103 serverul nu are suficient\u0103 memorie RAM pentru toate solicit\u0103rile, ESXi \u00eencepe s\u0103 aplice tehnici de optimizare a consumului de memorie (memory reclamation techniques). \u00cen caz contrar, sistemele de operare ale VM-urilor ar c\u0103dea cu erori de acces la RAM. <\/p>\n

Ce tehnici s\u0103 aplice ESXi depinde de gradul de ocupare a memoriei RAM:<\/p>\n

Starea memoriei<\/b><\/p>\n

Limit\u0103<\/b><\/p>\n

Ac\u021biuni<\/b><\/p>\n

Ridicat<\/p>\n

400% din minFree<\/p>\n

Dup\u0103 atingerea limitei superioare, paginile mari de memorie sunt \u00eemp\u0103r\u021bite \u00een pagini mici (TPS func\u021bioneaz\u0103 \u00een modul standard).<\/p>\n

Clear<\/p>\n

100% din minFree<\/p>\n

Paginile mari de memorie sunt \u00eemp\u0103r\u021bite \u00een pagini mici, TPS func\u021bioneaz\u0103 for\u021bat.<\/p>\n

Moale<\/p>\n

64% din minFree<\/p>\n

TPS + Balloon<\/p>\n

Dur<\/p>\n

32% din minFree<\/p>\n

TPS + Compresie + Swap<\/p>\n

Low<\/p>\n

16% din minFree<\/p>\n

Compresie + Swap + Blocare<\/p>\n

Sursa<\/a><\/noindex> <\/p>\n

minFree este memoria RAM necesar\u0103 pentru func\u021bionarea hipervizorului. <\/p>\n

P\u00e2n\u0103 la ESXi 4.1 inclusiv, minFree era implicit un procent fix \u2014 6% din volumul de memorie RAM a serverului (procentul putea fi schimbat prin op\u021biunea Mem.MinFreePct pe ESXi). \u00cen versiunile mai recente, din cauza cre\u0219terii dimensiunii memoriei serverelor, minFree a \u00eenceput s\u0103 fie calculat \u00een func\u021bie de volumul memoriei gazd\u0103, \u0219i nu ca o valoare procentual\u0103 fix\u0103. <\/p>\n

Valoarea minFree (implicit) este calculat\u0103 astfel:<\/p>\n

Procentajul de memorie rezervat pentru minFree<\/b><\/p>\n

Interval de memorie<\/b><\/p>\n

6%<\/p>\n

0-4 GB<\/p>\n

4%<\/p>\n

4-12 GB<\/p>\n

2%<\/p>\n

12-28 GB<\/p>\n

1%<\/p>\n

Memoria r\u0103mas\u0103<\/p>\n

Sursa<\/a><\/noindex><\/p>\n

De exemplu, pentru un server cu 128 GB RAM, valoarea MinFree va fi:
\nMinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
\nValoarea efectiv\u0103 poate varia cu c\u00e2teva sute de MB, \u00een func\u021bie de server \u0219i de memoria RAM.<\/p>\n

Procentajul de memorie rezervat pentru minFree<\/b><\/p>\n

Interval de memorie<\/b><\/p>\n

Valoarea pentru 128 GB<\/b><\/p>\n

6%<\/p>\n

0-4 GB<\/p>\n

245,76 MB<\/p>\n

4%<\/p>\n

4-12 GB<\/p>\n

327,68 MB<\/p>\n

2%<\/p>\n

12-28 GB<\/p>\n

327,68 MB<\/p>\n

1%<\/p>\n

Memoria r\u0103mas\u0103 (100 GB)<\/p>\n

1024 MB<\/p>\n

\nDe obicei, pentru medii productive, se poate considera c\u0103 singurul stadiu normal este High. Pentru mediile de testare \u0219i dezvoltare, st\u0103rile Clear\/Soft pot fi acceptabile. Dac\u0103 mai pu\u021bin de 64% din memorie este disponibil\u0103 pe gazd\u0103, atunci ma\u0219inile virtuale care ruleaz\u0103 pe aceasta vor avea cu siguran\u021b\u0103 probleme de performan\u021b\u0103.<\/p>\n

\u00cen fiecare stare se aplic\u0103 tehnici specifice de recuperare a memoriei, \u00eencep\u00e2nd cu TPS, care influen\u021beaz\u0103 practic deloc performan\u021ba ma\u0219inilor virtuale, \u0219i ajung\u00e2nd p\u00e2n\u0103 la Swapping. Voi explica acestea \u00een detaliu. <\/p>\n

Transparent Page Sharing (TPS).<\/b> TPS este, pe scurt, deduplicarea paginilor de memorie RAM ale ma\u0219inilor virtuale de pe server.<\/p>\n

ESXi caut\u0103 pagini identice de memorie RAM ale ma\u0219inilor virtuale, calcul\u00e2nd \u0219i compar\u00e2nd suma hash a paginilor, \u0219i \u0219terge duplicatele, \u00eenlocuindu-le cu referin\u021be la aceea\u0219i pagin\u0103 \u00een memoria fizic\u0103 a serverului. Ca urmare, consumul de memorie fizic\u0103 scade \u0219i se poate ob\u021bine o anumit\u0103 reaprovizionare a memoriei practic f\u0103r\u0103 sc\u0103derea performan\u021bei.<\/p>\n

\"Analiza
\nSursa<\/a><\/noindex><\/p>\n

Acest mecanism func\u021bioneaz\u0103 doar pentru paginile de memorie de dimensiune 4 KB (pagine mici). Hypervisorul nu \u00eencearc\u0103 nici m\u0103car s\u0103 deduplicate paginile de dimensiune 2 MB (pagine mari): \u0219ansa de a g\u0103si pagini identice de aceast\u0103 dimensiune nu este mare.<\/p>\n

\u00cen mod implicit, ESXi aloc\u0103 memorie paginilor mari. Fragmentarea paginilor mari \u00een pagini mici \u00eencepe la atingerea pragului st\u0103rii High \u0219i se desf\u0103\u0219oar\u0103 for\u021bat atunci c\u00e2nd se atinge starea Clear (vezi tabelul st\u0103rilor hypervisor-ului).<\/p>\n

Dac\u0103 dori\u021bi ca TPS s\u0103 \u00eenceap\u0103 s\u0103 func\u021bioneze f\u0103r\u0103 a a\u0219tepta completarea memoriei gazdei, \u00een Op\u021biuni avansate ESXi trebuie s\u0103 seta\u021bi valoarea \u201cMem.AllocGuestLargePage\u201d<\/i> la 0 (implicit 1). Atunci alocarea paginilor mari de memorie pentru ma\u0219inile virtuale va fi dezactivat\u0103.<\/p>\n

Din decembrie 2014, \u00een toate versiunile ESXi, TPS \u00eentre VM-uri este dezactivat \u00een mod implicit, deoarece s-a descoperit o vulnerabilitate, care teoretic permitea accesul dintr-o VM la memoria unei alte VM. Detaliile sunt aici. Informa\u021bii despre implementarea practic\u0103 a exploat\u0103rii vulnerabilit\u0103\u021bii TPS nu am \u00eent\u00e2lnit.<\/p>\n

Politica TPS este controlat\u0103 prin op\u021biunea avansat\u0103 \u201cMem.ShareForceSalting\u201d<\/i> pe ESXi:
\n0 \u2014 TPS \u00eentre VM-uri. TPS func\u021bioneaz\u0103 pentru paginile diferitelor VM-uri;
\n1 \u2013 TPS pentru VM-uri cu acela\u0219i valoare \u201csched.mem.pshare.salt\u201d \u00een VMX;
\n2 (implicit) \u2013 TPS intra-VM. TPS func\u021bioneaz\u0103 pentru paginile din interiorul VM-ului.<\/p>\n

Este sigur c\u0103 are sens s\u0103 dezactiva\u021bi paginile mari \u0219i s\u0103 activa\u021bi Inter-VM TPS pe standurile de testare. De asemenea, aceasta poate fi utilizat\u0103 pentru standuri cu un num\u0103r mare de VM-uri similare. De exemplu, pe standurile VDI, economiile de memorie fizic\u0103 pot ajunge la zeci de procente. <\/p>\n

Memory Ballooning.<\/b> Ballooning-ul nu mai este o tehnic\u0103 at\u00e2t de inofensiv\u0103 \u0219i transparent\u0103 pentru sistemul de operare al VM-ului, precum TPS. Dar, cu o aplicare corect\u0103, se poate tr\u0103i \u0219i chiar lucra cu Ballooning.<\/p>\n

\u00cempreun\u0103 cu VMware Tools, pe VM se instaleaz\u0103 un driver special, numit Balloon Driver (sau vmmemctl). C\u00e2nd hipervizorul \u00eencepe s\u0103 nu mai aib\u0103 suficient\u0103 memorie fizic\u0103 \u0219i trece \u00een starea Soft, ESXi cere VM-ului s\u0103 returneze memoria RAM neutilizat\u0103 prin acest Balloon Driver. Driverul, la r\u00e2ndul s\u0103u, func\u021bioneaz\u0103 la nivelul sistemului de operare \u0219i solicit\u0103 memorie liber\u0103 de la acesta. Hipervizorul vede ce pagini de memorie fizic\u0103 a ocupat Balloon Driver-ul, ia memoria de la ma\u0219ina virtual\u0103 \u0219i o returneaz\u0103 gazdei. Nu apar probleme cu func\u021bionarea sistemului de operare, deoarece la nivelul OS memoria este ocupat\u0103 de Balloon Driver. Implicit, Balloon Driver-ul poate lua p\u00e2n\u0103 la 65% din memoria VM-ului.<\/p>\n

Dac\u0103 VMware Tools nu sunt instalate pe VM sau Ballooning-ul este dezactivat (nu recomand, dar exist\u0103 KB<\/a><\/noindex>:), hipervizorul trece imediat la tehnici mai dure de recuperare a memoriei. Concluzie: asigura\u021bi-v\u0103 c\u0103 VMware Tools sunt instalate pe VM.<\/p>\n

\"Analiza
\nFunc\u021bionarea Balloon Driver-ului poate fi verificat\u0103 din OS prin VMware Tools.<\/i>.<\/p>\n

Memory Compression.<\/b> Aceast\u0103 tehnic\u0103 este utilizat\u0103 atunci c\u00e2nd ESXi ajunge \u00een starea Hard. A\u0219a cum sugereaz\u0103 numele, ESXi \u00eencearc\u0103 s\u0103 comprime o pagin\u0103 de 4 Kbyte de memorie RAM la 2 Kbyte \u0219i, astfel, s\u0103 elibereze pu\u021bin spa\u021biu \u00een memoria fizic\u0103 a serverului. Aceast\u0103 tehnic\u0103 cre\u0219te semnificativ timpul de acces la con\u021binutul paginilor de memorie RAM ale VM-ului, deoarece pagina trebuie s\u0103 fie dezvoltat\u0103 anterior. Uneori, nu toate paginile pot fi comprimate, iar procesul \u00een sine dureaz\u0103 ceva timp. Prin urmare, aceast\u0103 tehnic\u0103 nu este foarte eficient\u0103 \u00een practic\u0103.<\/p>\n

Memory Swapping.<\/b> Dup\u0103 o scurt\u0103 faz\u0103 de Memory Compression, ESXi trece practic inevitabil (dac\u0103 VM-urile nu au fost mutate pe alte gazde sau nu au fost oprite) la Swapping. \u0218i dac\u0103 a r\u0103mas foarte pu\u021bin\u0103 memorie (starea Low), atunci hipervizorul \u00eenceteaz\u0103 s\u0103 mai aloce VM-ului pagini de memorie, ceea ce poate provoca probleme \u00een sistemele de operare gazd\u0103 ale VM-ului.<\/p>\n

Iat\u0103 cum func\u021bioneaz\u0103 Swapping. C\u00e2nd se porne\u0219te o ma\u0219in\u0103 virtual\u0103, se creeaz\u0103 un fi\u0219ier cu extensia .vswp. Dimensiunea acestuia este egal\u0103 cu memoria RAM nerezervat\u0103 a MV: aceasta reprezint\u0103 diferen\u021ba dintre memoria configurat\u0103 \u0219i cea rezervat\u0103. Atunci c\u00e2nd se utilizeaz\u0103 Swapping, ESXi descarc\u0103 paginile de memorie ale ma\u0219inii virtuale \u00een acest fi\u0219ier \u0219i \u00eencepe s\u0103 lucreze cu acesta \u00een loc de memoria fizic\u0103 a serverului. Evident, aceast\u0103 a\u0219a-numit\u0103 \u201ememorie operativ\u0103\u201d este cu c\u00e2teva ordine de m\u0103rime mai lent\u0103 dec\u00e2t cea real\u0103, chiar dac\u0103 .vswp se afl\u0103 pe un stocare rapid\u0103.<\/p>\n

Spre deosebire de Ballooning, c\u00e2nd MV-ului i se iau pagini neutilizate, la Swapping paginile care sunt active \u00een sistemul de operare sau \u00een aplica\u021biile din MV pot fi mutate pe disc. Drept urmare, performan\u021ba MV-ului scade, ajung\u00e2nd p\u00e2n\u0103 la blocaje. MV-ul func\u021bioneaz\u0103 formal \u0219i cel pu\u021bin poate fi oprit corect din sistemul de operare. Dac\u0103 ave\u021bi r\u0103bdare\ud83d\ude09<\/p>\n

Dac\u0103 MV-urile au ajuns \u00een Swap, aceasta este o situa\u021bie anormal\u0103 pe care ar trebui s\u0103 o evita\u021bi c\u00e2t mai mult posibil.<\/p>\n

Principalele metrici de performan\u021b\u0103 a memoriei ma\u0219inii virtuale<\/h3>\n

\nIat\u0103-ne ajung\u00e2nd la esen\u021bial. Pentru monitorizarea st\u0103rii memoriei \u00een MV, exist\u0103 urm\u0103toarele metrici:<\/p>\n

Activ<\/b> \u2014 arat\u0103 volumul de memorie RAM (Kbyte) la care MV-ul a avut acces \u00een perioada de m\u0103surare anterioar\u0103.<\/p>\n

Utilizare<\/b> \u2014 acela\u0219i lucru ca Activ, dar \u00een procente din memoria RAM configurat\u0103 a MV-ului. Este calculat folosind urm\u0103toarea formul\u0103: activ \u00f7 dimensiunea memoriei virtuale configurate a ma\u0219inii.
\nO Utilizare \u0219i Activ\u0103 ridicate nu sunt neap\u0103rat un indicator al problemelor de performan\u021b\u0103 ale MV-ului. Dac\u0103 MV-ul utilizeaz\u0103 agresiv memoria (de cel pu\u021bin, are acces la aceasta), nu \u00eenseamn\u0103 c\u0103 \u00eei lipse\u0219te. Mai degrab\u0103, este un motiv s\u0103 verifica\u021bi ce se \u00eent\u00e2mpl\u0103 \u00een sistemul de operare.
\nExist\u0103 o Alarm\u0103 standard pentru Utilizarea Memoriei pentru MV:<\/p>\n

\"Analiza
\n
\nPartajat<\/b> \u2014 volumul de memorie RAM al MV-ului, deduplicat folosind TPS (\u00een cadrul MV-ului sau \u00eentre MV-uri).<\/p>\n

Acordat<\/b> \u2014 volumul de memorie fizic\u0103 a gazdei (Kbyte), care a fost alocat MV-ului. Include Shared.<\/p>\n

Consumpt<\/b> (Acordat \u2014 Shared) \u2014 volumul de memorie fizic\u0103 (Kbyte) consumat de MV de la gazd\u0103. Nu include Shared.<\/p>\n

Dac\u0103 o parte din memoria MV-ului este alocat\u0103 nu din memoria fizic\u0103 a gazdei, ci din swap-file sau memoria este luat\u0103 de la MV prin Balloon Driver, acest volum nu este inclus \u00een Acordat \u0219i Consumpt.
\nValorile mari pentru Granted \u0219i Consumed sunt perfect normale. Sistemul de operare absoarbe treptat memorie de la hypervisor \u0219i nu o returneaz\u0103. \u00cen timp, pentru o VM activ\u0103, valorile acestor contoare se apropie de cantitatea de memorie configurat\u0103 \u0219i r\u0103m\u00e2n acolo.<\/p>\n

Zero<\/b> \u2014 cantitatea de memorie RAM a VM-ului (KB) care con\u021bine zerouri. Aceast\u0103 memorie este considerat\u0103 liber\u0103 de hypervisor \u0219i poate fi alocat\u0103 altor ma\u0219ini virtuale. Dup\u0103 ce sistemul de operare gazd\u0103 a scris ceva \u00een memoria zero, aceasta trece \u00een Consumed \u0219i nu mai revine.<\/p>\n

Reserved Overhead<\/b> \u2014 cantitatea de memorie RAM a VM-ului (KB) rezervat\u0103 de hypervisor pentru func\u021bionarea VM-ului. Acesta este un volum mic, dar trebuie s\u0103 fie disponibil pe gazd\u0103, altfel VM-ul nu va porni.<\/p>\n

Balloon<\/b> \u2014 cantitatea de memorie RAM (KB) extras\u0103 de la VM prin intermediul Balloon Driver.<\/p>\n

Compressed<\/b> \u2014 cantitatea de memorie RAM (KB) care a reu\u0219it s\u0103 fie comprimat\u0103.<\/p>\n

Swapped<\/b> \u2014 cantitatea de memorie RAM (KB) care, din lips\u0103 de memorie fizic\u0103 pe server, a fost mutat\u0103 pe disc.
\nBalloon \u0219i ceilal\u021bi indicatori ai tehnicilor de recuperare a memoriei sunt egali cu zero.<\/p>\n

A\u0219a arat\u0103 un grafic cu contoarele Memory pentru o VM care func\u021bioneaz\u0103 normal cu 150 GB de memorie RAM.<\/p>\n

\"Analiza
\n
\n\u00cen graficul de mai jos, VM-ul are probleme evidente. Sub grafic se poate observa c\u0103 pentru aceast\u0103 VM au fost utilizate toate tehnicile descrise pentru gestionarea memoriei. Balloon pentru aceast\u0103 VM este mult mai mare dec\u00e2t Consumed. De fapt, VM-ul este mai degrab\u0103 mort dec\u00e2t viu. <\/p>\n

\"Analiza
\n<\/p>\n

ESXTOP<\/h3>\n

\nA\u0219a cum se \u00eent\u00e2mpl\u0103 \u0219i cu CPU, dac\u0103 dorim s\u0103 evalu\u0103m rapid situa\u021bia pe gazd\u0103, precum \u0219i dinamica acesteia la intervale de p\u00e2n\u0103 la 2 secunde, ar trebui s\u0103 folosim ESXTOP.<\/p>\n

Ecranul ESXTOP pentru Memory se deschide cu tasta \u201em\u201d \u0219i arat\u0103 astfel (c\u00e2mpurile selectate: B,D,H,J,K,L,O):<\/p>\n

\"Analiza
\n
\nParametrii urm\u0103tori ne vor interesa: <\/p>\n

Mem overcommit avg<\/b> \u2014 valoarea medie a supra\u00eenc\u0103rc\u0103rii memoriei pe gazd\u0103 \u00een ultimele 1, 5 \u0219i 15 minute. Dac\u0103 este mai mare de zero, este un motiv s\u0103 verific\u0103m ce se \u00eent\u00e2mpl\u0103, dar nu este \u00eentotdeauna un indicator al existen\u021bei problemelor.<\/p>\n

\u00cen r\u00e2ndurile PMEM\/MB<\/b> \u0219i VMKMEM\/MB<\/b> \u2014 informa\u021bii despre memoria fizic\u0103 a serverului \u0219i memoria disponibil\u0103 VMkernel. Din detalii, aici putem observa valoarea minfree (\u00een MB), starea gazdei \u00een ceea ce prive\u0219te memoria (\u00een cazul nostru, high).<\/p>\n

\u00cen r\u00e2ndul NUMA\/MB<\/b> se poate observa distribu\u021bia memoriei RAM pe nodurile NUMA (soclu). \u00cen acest exemplu, distribu\u021bia este inegal\u0103, ceea ce nu este foarte bine.<\/p>\n

Urm\u0103torul este un rezumat general al statisticilor serverului privind tehnicile de recuperare a memoriei:<\/p>\n

PSHARE\/MB<\/b> \u2014 aceasta este statistica TPS;<\/p>\n

SWAP\/MB<\/b> \u2014 statistic\u0103 utilizare Swap;<\/p>\n

ZIP\/MB<\/b> \u2014 statistic\u0103 pentru comprimarea paginilor de memorie;<\/p>\n

MEMCTL\/MB<\/b> \u2014 statistic\u0103 utilizare Balloon Driver.<\/p>\n

Pentru fiecare VM, ne-ar putea interesa urm\u0103toarele informa\u021bii. Am ascuns numele VM-urilor pentru a nu confunda audien\u021ba :). Dac\u0103 metrica ESXTOP este similar\u0103 cu contorul din vSphere, ofer contorul corespunz\u0103tor. <\/p>\n

MEMSZ<\/b> \u2014 volumul de memorie configurat pe VM (MB).
\nMEMSZ = GRANT + MCTLSZ + SWCUR + untouched.<\/p>\n

GRANT<\/b> \u2014 Grantat \u00een MB.<\/p>\n

TCHD<\/b> \u2014 Activ \u00een MB.<\/p>\n

MCTL?<\/b> \u2014 Dac\u0103 Balloon Driver este instalat pe VM.<\/p>\n

MCTLSZ<\/b> \u2014 Balloon \u00een MB.<\/p>\n

MCTLGT<\/b> \u2014 volumul de memorie RAM (MB) pe care ESXi vrea s\u0103-l recupereze de la VM prin Balloon Driver (Memctl Target).<\/p>\n

MCTLMAX<\/b> \u2014 volumul maxim de memorie RAM (MB) pe care ESXi poate s\u0103-l recupereze de la VM prin Balloon Driver.<\/p>\n

SWCUR<\/b> \u2014 volumul curent de memorie RAM (MB) alocat VM-ului din fi\u0219ierul Swap. <\/p>\n

SWGT<\/b> \u2014 volumul de memorie RAM (MB) pe care ESXi dore\u0219te s\u0103-l aloce VM-ului din fi\u0219ierul Swap (Swap Target).<\/p>\n

De asemenea, prin ESXTOP se poate vizualiza informa\u021bii mai detaliate despre topologia NUMA a VM-ului. Pentru aceasta, trebuie selectate c\u00e2mpurile D,G:<\/p>\n

\"Analiza
\n
\nNHN<\/b> \u2013 nodurile NUMA pe care se afl\u0103 VM-ul. Aici se pot observa imediat VM-uri mari care nu \u00eencap pe un singur nod NUMA.<\/p>\n

NRMEM<\/b> \u2013 c\u00e2\u021bi megabai\u021bi de memorie ia VM-ul de pe un nod NUMA \u00eendep\u0103rtat.<\/p>\n

NLMEM<\/b> \u2013 c\u00e2\u021bi megabai\u021bi de memorie ia VM-ul de pe un nod NUMA local.<\/p>\n

N%L<\/b> \u2013 procentul de memorie VM pe nodul NUMA local (dac\u0103 este mai mic de 80% \u2014 pot ap\u0103rea probleme de performan\u021b\u0103).<\/p>\n

Memorie pe hypervizor<\/h3>\n

\nDac\u0103 contoarele CPU pe hypervizor de obicei nu prezint\u0103 un interes deosebit, \u00een cazul memoriei situa\u021bia este invers\u0103. Un nivel ridicat de utilizare a memoriei pe VM nu \u00eenseamn\u0103 \u00eentotdeauna c\u0103 exist\u0103 o problem\u0103 de performan\u021b\u0103, dar un nivel ridicat de utilizare a memoriei pe hypervizor activeaz\u0103 tehnicile de gestionare a memoriei \u0219i provoac\u0103 probleme de performan\u021b\u0103 ale VM-ului. Este important s\u0103 monitoriz\u0103m alertele de utilizare a memoriei gazdei \u0219i s\u0103 evit\u0103m ca VM-urile s\u0103 ajung\u0103 \u00een Swap.<\/p>\n

\"Analiza
\n
\n\"Analiza
\n<\/p>\n

Unswap<\/h3>\n

\nDac\u0103 VM-ul a ajuns \u00een Swap, performan\u021ba sa scade semnificativ. Urmele Ballooning-ului \u0219i comprim\u0103rii dispar rapid dup\u0103 ce apare memorie RAM liber\u0103 pe host, dar \u00eentoarcerea din Swap \u00een memoria RAM a serverului nu se face deloc cu repeziciune.
\nP\u00e2n\u0103 la versiunea ESXi 6.0, singura modalitate de \u00eencredere \u0219i rapid\u0103 de a scoate VM-urile din Swap era repornirea (mai precis, oprirea\/\nc \u0219i apoi activarea contului). \u00cencep\u00e2nd cu ESXi 6.0, a ap\u0103rut o metod\u0103, de\u0219i nu tocmai oficial\u0103, dar func\u021bional\u0103 \u0219i de \u00eencredere de a scoate VM-urile din Swap. La una dintre conferin\u021be, am reu\u0219it s\u0103 discut cu unul dintre inginerii VMware care se ocup\u0103 de CPU Scheduler. El a confirmat c\u0103 aceast\u0103 metod\u0103 este destul de func\u021bional\u0103 \u0219i sigur\u0103. Din experien\u021ba noastr\u0103, nu am avut probleme cu aceasta.<\/p>\n

Comenzile propriu-zise pentru scoaterea VM-urilor din Swap a descris<\/a><\/noindex> Duncan Epping. Nu voi repeta descrierea detaliat\u0103, voi da doar un exemplu de utilizare. Dup\u0103 cum se vede \u00een captura de ecran, dup\u0103 un timp, dup\u0103 executarea comenzii specifice, Swap-ul de pe VM dispare.<\/p>\n

\"Analiza
\n<\/p>\n

Sfaturi pentru gestionarea memoriei RAM pe ESXi<\/h3>\n

\n\u00cen cele din urm\u0103, voi oferi c\u00e2teva sfaturi care v\u0103 vor ajuta s\u0103 evita\u021bi problemele de performan\u021b\u0103 ale VM-ului din cauza memoriei RAM:<\/p>\n