Anàlisi del rendiment de VM a VMware vSphere. Part 2: Memòria

Anàlisi del rendiment de VM a VMware vSphere. Part 2: Memòria

Part 1. Sobre la CPU

En aquest article, parlarem dels comptadors de rendiment de la memòria d'accés aleatori (RAM) a vSphere.
Sembla que amb la memòria tot queda més clar que amb el processador: si una màquina virtual té problemes de rendiment, és difícil no notar-los. Però si apareixen, és molt més difícil tractar-los. Però primer és el primer.

Una mica de teoria

La memòria RAM de les màquines virtuals s'agafa de la memòria del servidor on s'executen les màquines virtuals. És força evident :). Si la memòria RAM del servidor no és suficient per a tothom, ESXi comença a utilitzar tècniques de recuperació de memòria per optimitzar el consum de memòria RAM. En cas contrari, els sistemes operatius de VM es bloquejarien amb errors d'accés a la memòria RAM.

Quines tècniques utilitzar ESXi decideixen en funció de la càrrega de RAM:

Estat de la memòria

frontera

Activitat

alt

400% de minGratis

Després d'arribar al límit superior, les pàgines de memòria grans es divideixen en petites (TPS funciona en mode estàndard).

Clear

100% de minGratis

Les pàgines de memòria grans es divideixen en petites, TPS es veu obligat a funcionar.

Suau

64% de minGratis

TPS + globus

Dur

32% de minGratis

TPS + Compressió + Canvi

Sota

16% de minGratis

Comprimir + Canviar + Bloquejar

Font

minFree és la memòria RAM necessària perquè l'hipervisor funcioni.

Abans d'ESXi 4.1 inclòs, minFree es va solucionar de manera predeterminada: el 6% de la memòria RAM del servidor (el percentatge es podia canviar mitjançant l'opció Mem.MinFreePct a ESXi). En versions posteriors, a causa de l'augment de la mida de la memòria als servidors, minFree es va començar a calcular en funció de la quantitat de memòria de l'amfitrió, i no com un percentatge fix.

El valor minFree (per defecte) es calcula de la següent manera:

Percentatge de memòria reservada per a minFree

Interval de memòria

6%

0-4 GB

4%

4-12 GB

2%

12-28 GB

1%

Memòria restant

Font

Per exemple, per a un servidor amb 128 GB de RAM, el valor de MinFree seria:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
El valor real pot variar en un parell de centenars de MB, depèn del servidor i la memòria RAM.

Percentatge de memòria reservada per a minFree

Interval de memòria

Valor de 128 GB

6%

0-4 GB

245,76 MB

4%

4-12 GB

327,68 MB

2%

12-28 GB

327,68 MB

1%

Memòria restant (100 GB)

1024 MB

Normalment, per a estands productius, només l'estat Alt es pot considerar normal. Per als bancs de prova i desenvolupament, els estats Clear/Soft poden ser acceptables. Si la memòria RAM de l'amfitrió és inferior al 64% de MinFree, les màquines virtuals que s'hi executen definitivament tenen problemes de rendiment.

En cada estat, s'apliquen determinades tècniques de recuperació de memòria, començant per TPS, que pràcticament no afecta el rendiment de la VM, i acabant per Swapping. Us explicaré més coses sobre ells.

Compartició de pàgines transparents (TPS). TPS és, a grans trets, la deduplicació de pàgines de memòria de màquines virtuals en un servidor.

ESXi cerca pàgines idèntiques de la memòria RAM de la màquina virtual comptant i comparant la suma hash de les pàgines i elimina les pàgines duplicades, substituint-les per enllaços a la mateixa pàgina a la memòria física del servidor. Com a resultat, es redueix el consum de memòria física i es pot aconseguir una sobresubscripció de memòria amb poca o cap degradació del rendiment.

Anàlisi del rendiment de VM a VMware vSphere. Part 2: Memòria
Font

Aquest mecanisme només funciona per a pàgines de memòria de 4 KB (pàgines petites). L'hipervisor ni tan sols intenta deduplicar pàgines de 2 MB (pàgines grans): la possibilitat de trobar pàgines idèntiques d'aquesta mida no és gran.

Per defecte, ESXi assigna memòria a pàgines grans. La divisió de pàgines grans en pàgines petites comença quan s'arriba al llindar d'estat Alt i es força quan s'arriba a l'estat Esborra (vegeu la taula d'estats de l'hipervisor).

Si voleu que TPS comenci a funcionar sense esperar que s'ompli la memòria RAM de l'amfitrió, a Opcions avançades ESXi heu d'establir el valor "Mem.AllocGuestLargePage" a 0 (per defecte 1). Aleshores, es desactivarà l'assignació de pàgines de memòria grans per a màquines virtuals.

Des del desembre de 2014, en totes les versions d'ESXi, el TPS entre VM s'ha desactivat de manera predeterminada, ja que es va trobar una vulnerabilitat que teòricament permet l'accés des d'una VM a la RAM d'una altra VM. Detalls aquí. No he trobat informació sobre la implementació pràctica de l'explotació de la vulnerabilitat TPS.

Política de TPS controlada mitjançant opció avançada "Mem.ShareForceSalting" a ESXi:
0 - Inter-VM TPS. TPS funciona per a pàgines de diferents màquines virtuals;
1 - TPS per a VM amb el mateix valor "sched.mem.pshare.salt" a VMX;
2 (per defecte) - TPS intra-VM. TPS funciona per a pàgines dins de la VM.

Sens dubte, té sentit desactivar pàgines grans i activar el TPS Inter-VM als bancs de proves. També es pot utilitzar per a estands amb un gran nombre de VM del mateix tipus. Per exemple, en estands amb VDI, l'estalvi en memòria física pot arribar a desenes de per cent.

globus de memòria. El globus ja no és una tècnica tan inofensiva i transparent per al sistema operatiu de VM com TPS. Però amb l'aplicació adequada, podeu viure i fins i tot treballar amb Ballooning.

Juntament amb Vmware Tools, s'instal·la un controlador especial anomenat Balloon Driver (també conegut com vmmemctl) a la màquina virtual. Quan l'hipervisor comença a quedar-se sense memòria física i entra a l'estat suau, ESXi demana a la màquina virtual que recuperi la memòria RAM no utilitzada mitjançant aquest controlador de globus. El controlador, al seu torn, funciona a nivell de sistema operatiu i li demana memòria lliure. L'hipervisor veu quines pàgines de memòria física ha ocupat el controlador de globus, agafa la memòria de la màquina virtual i la torna a l'amfitrió. No hi ha problemes amb el funcionament del sistema operatiu, ja que a nivell del sistema operatiu la memòria està ocupada pel controlador de globus. De manera predeterminada, el controlador de globus pot ocupar fins a un 65% de la memòria de la màquina virtual.

Si VMware Tools no està instal·lat a la màquina virtual o si està desactivat el Ballooning (no ho recomano, però hi ha KB:), l'hipervisor passa immediatament a tècniques d'eliminació de memòria més estrictes. Conclusió: assegureu-vos que VMware Tools estigui a la màquina virtual.

Anàlisi del rendiment de VM a VMware vSphere. Part 2: Memòria
El funcionament del controlador de globus es pot comprovar des del sistema operatiu mitjançant VMware Tools.

compressió de memòria. Aquesta tècnica s'utilitza quan ESXi arriba a l'estat Hard. Com el seu nom indica, ESXi intenta reduir una pàgina de 4 KB de RAM a 2 KB i així alliberar espai a la memòria física del servidor. Aquesta tècnica augmenta significativament el temps d'accés als continguts de les pàgines RAM de la VM, ja que primer s'ha de descomprimir la pàgina. De vegades no totes les pàgines es poden comprimir i el procés en si triga una mica. Per tant, aquesta tècnica no és gaire efectiva a la pràctica.

intercanvi de memòria. Després d'una breu fase de compressió de memòria, ESXi gairebé inevitablement (si les màquines virtuals no han marxat cap a altres amfitrions o s'han apagat) canviarà a l'intercanvi. I si queda molt poca memòria (estat baix), l'hipervisor també deixa d'assignar pàgines de memòria a la màquina virtual, cosa que pot causar problemes al sistema operatiu convidat de la màquina virtual.

Aquí és com funciona l'intercanvi. Quan engegueu una màquina virtual, es crea un fitxer amb l'extensió .vswp. Té la mateixa mida que la memòria RAM no reservada de la VM: és la diferència entre la memòria configurada i la reservada. Quan l'intercanvi s'està executant, ESXi descarrega les pàgines de memòria de la màquina virtual en aquest fitxer i comença a treballar-hi en lloc de la memòria física del servidor. Per descomptat, aquesta memòria "operativa" és diversos ordres de magnitud més lenta que la real, fins i tot si .vswp es troba en un emmagatzematge ràpid.

A diferència de Ballooning, quan les pàgines no utilitzades es prenen de la VM, amb Swapping, les pàgines que s'utilitzen activament pel sistema operatiu o les aplicacions dins de la VM es poden moure al disc. Com a resultat, el rendiment de la màquina virtual baixa fins al punt de congelar-se. La màquina virtual funciona formalment i almenys es pot desactivar correctament des del sistema operatiu. Si tens paciència 😉

Si les màquines virtuals van anar a Swap, aquesta és una situació anormal, que és millor evitar-la si és possible.

Comptadors clau de rendiment de memòria VM

Així que vam arribar al punt principal. Per supervisar l'estat de la memòria a la màquina virtual, hi ha els comptadors següents:

Actiu — mostra la quantitat de RAM (KB) a la qual va tenir accés la màquina virtual durant el període de mesura anterior.

Ús - el mateix que Active, però com a percentatge de la RAM configurada de la VM. Calculat mitjançant la fórmula següent: activa ÷ mida de memòria configurada per màquina virtual.
L'ús elevat i l'actiu, respectivament, no sempre són un indicador dels problemes de rendiment de la màquina virtual. Si la màquina virtual utilitza la memòria de manera agressiva (almenys hi té accés), això no vol dir que no hi hagi prou memòria. Més aviat, és una ocasió per veure què està passant al sistema operatiu.
Hi ha una alarma d'ús de memòria estàndard per a màquines virtuals:

Anàlisi del rendiment de VM a VMware vSphere. Part 2: Memòria

Shared - la quantitat de RAM de VM desduplicada mitjançant TPS (dins de la VM o entre VM).

Concedit - la quantitat de memòria física de l'amfitrió (KB) que es va donar a la màquina virtual. Inclou Compartit.

Consumit (Concedit - Compartit): la quantitat de memòria física (KB) que la màquina virtual consumeix de l'amfitrió. No inclou Compartit.

Si una part de la memòria de la VM no es dóna de la memòria física de l'amfitrió, sinó del fitxer d'intercanvi, o la memòria s'agafa de la VM a través del controlador de globus, aquesta quantitat no es té en compte a Concedit i Consumit.
Els valors alts concedits i consumits són perfectament normals. El sistema operatiu pren gradualment la memòria de l'hipervisor i no la retorna. Amb el temps, en una màquina virtual en execució activa, els valors d'aquests comptadors s'acosten a la quantitat de memòria configurada i es mantenen allà.

zero — la quantitat de RAM de VM (KB), que conté zeros. Aquesta memòria es considera lliure per l'hipervisor i es pot donar a altres màquines virtuals. Després que el sistema operatiu convidat hagi escrit alguna cosa a la memòria posada a zero, entra a Consumed i no torna enrere.

Overhead reservat — la quantitat de RAM de VM, (KB) reservada per l'hipervisor per al funcionament de la VM. Aquesta és una quantitat petita, però ha d'estar disponible a l'amfitrió, en cas contrari, la màquina virtual no s'iniciarà.

Globus — la quantitat de RAM (KB) confiscada de la màquina virtual mitjançant el controlador de globus.

Comprimit - la quantitat de RAM (KB) que es va comprimir.

Intercanviada - la quantitat de RAM (KB) que, a causa de la manca de memòria física al servidor, es va traslladar al disc.
Els comptadors de globus i altres tècniques de recuperació de memòria són zero.

Així és com es veu el gràfic amb comptadors de memòria per a una màquina virtual que funciona normalment amb 150 GB de RAM.

Anàlisi del rendiment de VM a VMware vSphere. Part 2: Memòria

Al gràfic següent, la VM té problemes evidents. Sota el gràfic, podeu veure que per a aquesta màquina virtual s'han utilitzat totes les tècniques descrites per treballar amb RAM. El globus per a aquesta VM és molt més gran que el consumit. De fet, la VM està més morta que viva.

Anàlisi del rendiment de VM a VMware vSphere. Part 2: Memòria

ESXTOP

Igual que amb la CPU, si volem avaluar ràpidament la situació a l'amfitrió, així com la seva dinàmica amb un interval de fins a 2 segons, hauríem d'utilitzar ESXTOP.

La pantalla ESXTOP per Memòria es crida amb la tecla "m" i té aquest aspecte (els camps B, D, H, J, K, L, O estan seleccionats):

Anàlisi del rendiment de VM a VMware vSphere. Part 2: Memòria

Els següents paràmetres seran del nostre interès:

Mem overcommit mig - el valor mitjà de la sobresubscripció de memòria a l'amfitrió durant 1, 5 i 15 minuts. Si està per sobre de zero, aquesta és una ocasió per veure què està passant, però no sempre un indicador de problemes.

En línies PMEM/MB и VMKMEM/MB - informació sobre la memòria física del servidor i la memòria disponible per a VMkernel. Des de l'interessant aquí podeu veure el valor de minfree (en MB), l'estat de l'amfitrió a la memòria (en el nostre cas, alt).

En linia NUMA/MB podeu veure la distribució de la memòria RAM per nodes NUMA (sockets). En aquest exemple, la distribució és desigual, cosa que, en principi, no és gaire bona.

A continuació es mostren les estadístiques generals del servidor sobre tècniques de recuperació de memòria:

PSHARE/MB són estadístiques TPS;

SWAP/MB — Canviar estadístiques d'ús;

ZIP/MB — estadístiques de compressió de pàgines de memòria;

MEMCTL/MB — Estadístiques d'ús del controlador de globus.

Per a màquines virtuals individuals, ens pot interessar la informació següent. Vaig amagar els noms de VM per no confondre el públic :). Si la mètrica ESXTOP és similar al comptador de vSphere, dono el comptador corresponent.

MEMSZ — la quantitat de memòria configurada a la màquina virtual (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + sense tocar.

CONCESSIÓ — Atorgat a MB.

TCHD — Actiu en MB.

MCTL? - si el controlador de globus està instal·lat a la màquina virtual.

MCTLSZ — Globus a MB.

MCTLGT — la quantitat de RAM (MB) que ESXi vol agafar de la màquina virtual mitjançant el controlador de globus (Memctl Target).

MCTLMAX - la quantitat màxima de RAM (MB) que ESXi pot agafar de la màquina virtual mitjançant el controlador de globus.

SWCUR — la quantitat actual de RAM (MB) assignada a la màquina virtual des del fitxer Swap.

S.W.G.T. - la quantitat de RAM (MB) que ESXi vol donar a la VM des del fitxer Swap (Swap Target).

A més, mitjançant ESXTOP, podeu veure informació més detallada sobre la topologia NUMA de la VM. Per fer-ho, seleccioneu els camps D, G:

Anàlisi del rendiment de VM a VMware vSphere. Part 2: Memòria

PETIT – Nodes NUMA on es troba la VM. Aquí podeu notar immediatament vm ample, que no caben en un node NUMA.

NRMEM - quants megabytes de memòria pren la VM del node NUMA remot.

NLMEM - quants megabytes de memòria pren la VM del node NUMA local.

N%L – percentatge de memòria de VM al node NUMA local (si és inferior al 80%, es poden produir problemes de rendiment).

Memòria a l'hipervisor

Si els comptadors de CPU per a l'hipervisor no solen ser d'interès particular, la situació s'inverteix amb la memòria. L'ús elevat de memòria en una màquina virtual no sempre indica un problema de rendiment, però l'ús elevat de memòria en un hipervisor desencadena tècniques de gestió de memòria i provoca problemes de rendiment a la màquina virtual. Les alarmes d'ús de memòria de l'amfitrió s'han de supervisar per evitar que la màquina virtual entri a l'intercanvi.

Anàlisi del rendiment de VM a VMware vSphere. Part 2: Memòria

Anàlisi del rendiment de VM a VMware vSphere. Part 2: Memòria

desintercanviar

Si una màquina virtual està en intercanvi, el seu rendiment es redueix molt. Els rastres de globus i compressió desapareixen ràpidament després que la memòria RAM lliure aparegui a l'amfitrió, però la màquina virtual no té pressa per tornar de l'intercanvi a la memòria RAM del servidor.
Abans d'ESXi 6.0, l'única manera fiable i ràpida de treure una màquina virtual de Swap era reiniciar (per ser més precisos, apagar/encendre el contenidor). A partir de l'ESXi 6.0, tot i que no és del tot oficial, ha aparegut una manera fiable i funcional d'eliminar una VM de Swap. En una de les conferències, vaig poder parlar amb un dels enginyers de VMware a càrrec de CPU Scheduler. Va confirmar que el mètode funciona bastant i segur. Segons la nostra experiència, tampoc hi va haver problemes.

Les ordres reals per eliminar la VM de l'intercanvi descrit Duncan Epping. No repetiré una descripció detallada, només posaré un exemple del seu ús. Com podeu veure a la captura de pantalla, un temps després de l'execució de les ordres especificades, Swap desapareix a la VM.

Anàlisi del rendiment de VM a VMware vSphere. Part 2: Memòria

Consells de gestió de memòria ESXi

Finalment, aquí teniu alguns consells que us ajudaran a evitar problemes amb el rendiment de la màquina virtual a causa de la memòria RAM:

  • Eviteu la sobresubscripció de memòria en clústers productius. És desitjable tenir sempre un 20-30% de memòria lliure al clúster perquè DRS (i l'administrador) tinguin marge de maniobra i les màquines virtuals no entrin a l'intercanvi durant la migració. A més, no us oblideu del marge de tolerància a fallades. És desagradable quan, quan un servidor falla i la màquina virtual es reinicia mitjançant HA, algunes de les màquines també entren a l'intercanvi.
  • En infraestructures molt consolidades, intenteu NO crear màquines virtuals amb més de la meitat de la memòria de l'amfitrió. Això tornarà a ajudar a DRS a distribuir màquines virtuals entre els servidors del clúster sense cap problema. Aquesta regla, per descomptat, no és universal :).
  • Compte amb l'alarma d'ús de la memòria de l'amfitrió.
  • No oblideu instal·lar VMware Tools a la màquina virtual i no desactiveu els globus.
  • Penseu en habilitar el TPS entre VM i desactivar les pàgines grans en entorns VDI i de prova.
  • Si la màquina virtual té problemes de rendiment, comproveu si està utilitzant memòria d'un node NUMA remot.
  • Treu la teva VM de Swap el més aviat possible! Entre altres coses, si la VM està en Swap, per raons òbvies, el sistema d'emmagatzematge en pateix.

Això és tot per a mi sobre RAM. A continuació es mostra un article relacionat per a aquells que vulguin aprofundir en els detalls. El següent article estarà dedicat a storadzh.

links útilshttp://www.yellow-bricks.com/2015/03/02/what-happens-at-which-vsphere-memory-state/
http://www.yellow-bricks.com/2013/06/14/how-does-mem-minfreepct-work-with-vsphere-5-0-and-up/
https://www.vladan.fr/vmware-transparent-page-sharing-tps-explained/
http://www.yellow-bricks.com/2016/06/02/memory-pages-swapped-can-unswap/
https://kb.vmware.com/s/article/1002586
https://www.vladan.fr/what-is-vmware-memory-ballooning/
https://kb.vmware.com/s/article/2080735
https://kb.vmware.com/s/article/2017642
https://labs.vmware.com/vmtj/vmware-esx-memory-resource-management-swap
https://blogs.vmware.com/vsphere/2013/10/understanding-vsphere-active-memory.html
https://www.vmware.com/support/developer/converter-sdk/conv51_apireference/memory_counters.html
https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-65-monitoring-performance-guide.pdf

Font: www.habr.com

Afegeix comentari