In questo articolo parleremo dei contatori delle prestazioni della memoria RAM in vSphere.
Sembra che con la memoria tutto sia più chiaro rispetto al processore: se ci sono problemi di prestazioni sulla VM, è difficile non notarli. Tuttavia, affrontarli è molto più complicato. Ma andiamo con ordine.
Un po' di teoria
La memoria RAM delle macchine virtuali proviene dalla memoria del server su cui operano le VM. Questo è abbastanza ovvio:). Se la memoria RAM del server non è sufficiente per tutti, ESXi inizia ad applicare tecniche di ottimizzazione dei consumi di memoria (memory reclamation techniques). Altrimenti, i sistemi operativi delle VM andrebbero in crash con errori di accesso alla RAM.
Quali tecniche applicare, ESXi lo decide in base al carico della memoria RAM:
Stato della memoria
Limite
Azioni
Alto
400% di minFree
Dopo aver raggiunto il limite superiore, le grandi pagine di memoria vengono suddivise in piccole (TPS funziona in modalità standard).
Pulisci
100% di minFree
Le grandi pagine di memoria vengono suddivise in piccole, TPS funziona forzatamente.
Morbido
64% di minFree
TPS + Balloon
Duro
32% di minFree
TPS + Compress + Swap
Basso
16% di minFree
Compresso + Scambiare + Bloccare
minFree è la memoria RAM necessaria per il funzionamento dell'iperparavento.
Fino a ESXi 4.1 incluso, minFree era impostato di default a un valore fisso — 6% della memoria RAM del server (la percentuale poteva essere cambiata attraverso l'opzione Mem.MinFreePct su ESXi). Nelle versioni successive, a causa dell'aumento della capacità della memoria nei server, minFree è stata calcolata in base alla memoria del host anziché come valore percentuale fisso.
Il valore di minFree (di default) è calcolato nel seguente modo:
Percentuale di memoria riservata per minFree
Intervallo di memoria
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Memoria rimanente
Ad esempio, per un server con 128 GB di RAM, il valore di MinFree sarà:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Il valore effettivo può variare di qualche centinaio di MB, a seconda del server e della memoria RAM.
Percentuale di memoria riservata per minFree
Intervallo di memoria
Valore per 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 rimanente (100 GB)
1024 MB
In genere, solo lo stato High è considerato normale per ambienti produttivi. Per gli ambienti di test e sviluppo, possono essere accettabili gli stati Clear/Soft. Se la memoria disponibile sull'host scende sotto il 64% di MinFree, le VM in esecuzione su di esso riscontreranno sicuramente problemi di prestazioni.
In ogni stato vengono applicate specifiche tecniche di recupero della memoria, partendo dal TPS, che influisce poco sulle prestazioni delle VM, fino allo swapping. Ne parlerò più nel dettaglio.
Trasparent Page Sharing (TPS). Il TPS è, in parole semplici, la deduplicazione delle pagine di memoria RAM delle macchine virtuali su un server.
ESXi cerca pagine di memoria RAM identiche delle macchine virtuali, calcolando e confrontando l'hash delle pagine, e rimuove i duplicati sostituendoli con riferimenti alla stessa pagina nella memoria fisica del server. Di conseguenza, il consumo di memoria fisica diminuisce e si può ottenere una certa sovrascrittura della memoria praticamente senza ridurre le prestazioni.
Questo meccanismo funziona solo per le pagine di memoria dalle dimensioni di 4 Kbyte (piccole pagine). Le pagine di dimensioni 2 Mbyte (grandi pagine) non vengono nemmeno tentate di essere deduplicate dal hypervisor: la probabilità di trovare pagine identiche di tali dimensioni non è alta.
Per impostazione predefinita, ESXi assegna memoria alle grandi pagine. La separazione delle grandi pagine in piccole commence quando si raggiunge la soglia di stato High e avviene forzatamente quando si raggiunge lo stato Clear (vedi la tabella degli stati del hypervisor).
Se desideri che TPS inizi a funzionare senza attendere il riempimento della memoria del host, in Advanced Options di ESXi è necessario impostare il valore “Mem.AllocGuestLargePage” a 0 (di default 1). In questo modo, l'allocazione di grandi pagine di memoria per le macchine virtuali sarà disattivata.
Dal dicembre 2014, in tutte le versioni di ESXi, TPS tra VM è disattivato per impostazione predefinita, poiché è stata trovata una vulnerabilità che teoricamente consente di ottenere l'accesso alla memoria di lavoro di un'altra VM da una VM. Maggiori dettagli qui. Non ho trovato informazioni sull'implementazione pratica della vulnerabilità TPS.
La politica TPS è controllata tramite l'opzione avanzata “Mem.ShareForceSalting” su ESXi:
0 - Inter-VM TPS. TPS lavora per le pagine di diverse VM;
1 - TPS per VM con lo stesso valore “sched.mem.pshare.salt” in VMX;
2 (di default) - Intra-VM TPS. TPS lavora per le pagine interne della VM.
È decisamente sensato disattivare le grandi pagine e attivare Inter-VM TPS su ambienti di test. Può essere utilizzato anche in ambienti con un gran numero di VM omogenee. Ad esempio, negli ambienti con VDI, il risparmio di memoria fisica può raggiungere decine di percento.
Memory Ballooning. Il Ballooning non è più una tecnica così innocua e trasparente per il sistema operativo della VM come il TPS. Ma con un uso appropriato, si può convivere e persino lavorare con il Ballooning.
Insieme a Vmware Tools, viene installato un driver speciale sulla VM, chiamato Balloon Driver (o vmmemctl). Quando l'hypervisor inizia a mancare di memoria fisica e passa allo stato Soft, ESXi chiede alla VM di restituire la memoria RAM inutilizzata tramite questo Balloon Driver. Il driver, a sua volta, opera a livello di sistema operativo e richiede memoria libera allo stesso. L'hypervisor vede quali pagine di memoria fisica sono occupate dal Balloon Driver, sottrae memoria dalla macchina virtuale e la restituisce all'host. Non ci sono problemi con il funzionamento del sistema operativo poiché a livello di OS la memoria è occupata dal Balloon Driver. Di default, il Balloon Driver può sottrarre fino al 65% della memoria della VM.
Se sulla VM non sono installati VMware Tools o se il Ballooning è disattivato (non consiglio questa opzione, ma esiste :), l'hypervisor passa subito a tecniche più drastiche di sottrazione della memoria. Morale: assicurati che i VMware Tools siano installati sulla VM.
Il funzionamento del Balloon Driver può essere verificato dal sistema operativo tramite VMware Tools..
Memory Compression. Questa tecnica viene utilizzata quando l'ESXi raggiunge uno stato di Hard. Come suggerisce il nome, l'ESXi cerca di comprimere 4 KB di pagina di memoria RAM in 2 KB, liberando così un po' di spazio nella memoria fisica del server. Questa tecnica aumenta significativamente il tempo di accesso ai contenuti delle pagine di memoria delle VM, poiché la pagina deve essere decompressa in anticipo. A volte non tutte le pagine riescono a essere compressi e il processo stesso richiede del tempo. Pertanto, questa tecnica non è molto efficace nella pratica.
Memory Swapping. Dopo una breve fase di Compressione della Memoria, l'ESXi passa praticamente inevitabilmente a Swapping (se le VM non sono migrate su altri host o non sono spente). E se la memoria rimasta è molto poca (stato di Low), il hypervisor smette anche di allocare pagine di memoria alle VM, il che può causare problemi nei sistemi operativi guest delle VM.
Ecco come funziona lo Swapping. Quando si avvia una macchina virtuale, viene creato un file con estensione .vswp. Le dimensioni di questo file corrispondono alla memoria RAM non riservata della VM: è la differenza tra la memoria configurata e quella riservata. Durante l'operazione di Swapping, ESXi scarica le pagine della memoria della macchina virtuale in questo file e inizia a lavorare con esso invece della memoria fisica del server. Naturalmente, questa 'memoria' è di diversi ordini di grandezza più lenta rispetto a quella reale, anche se .vswp è memorizzato su uno storage veloce.
A differenza del Ballooning, dove vengono prelevate le pagine non utilizzate dalla VM, durante lo Swapping possono essere trasferite su disco pagine che sono attivamente utilizzate dal sistema operativo o dalle applicazioni all'interno della VM. Di conseguenza, le prestazioni della VM calano fino a bloccarsi completamente. La VM continua formalmente a funzionare e, almeno, può essere spenta correttamente dal sistema operativo. Se avrete pazienza 😉
Se le VM sono andate in Swap — si tratta di una situazione anomala che sarebbe meglio evitare il più possibile.
Principali contatori delle prestazioni della memoria della macchina virtuale
Eccoci arrivati al punto principale. Per monitorare lo stato della memoria nella VM, ci sono i seguenti contatori:
Active — mostra la quantità di memoria RAM (KB) a cui la VM ha avuto accesso nel periodo di misurazione precedente.
Utilizzo — è lo stesso di Attivo, ma in percentuale dalla memoria RAM configurata per la VM. Si calcola con la seguente formula: attivo ÷ dimensione della memoria configurata della macchina virtuale.
Un alto Utilizzo e Attivo, rispettivamente, non sono sempre indicatori di problemi di prestazioni della VM. Se la VM utilizza aggressivamente la memoria (almeno, vi accede), non significa necessariamente che ci sia una carenza di memoria. È più un motivo per esaminare cosa sta succedendo nel sistema operativo.
C'è un allarme standard per l'Utilizzo della Memoria per la VM:
Condiviso — quantità di memoria RAM della VM, deduplicata tramite TPS (all'interno della VM o tra VM).
Concessa — quantità di memoria fisica dell'host (KB) che è stata assegnata alla VM. Include la Condivisa.
Consumato (Concessa - Condivisa) — quantità di memoria fisica (KB) che la VM consuma dall'host. Non include la Condivisa.
Se una parte della memoria della VM è assegnata non dalla memoria fisica dell'host, ma da un file di swap, oppure la memoria è stata sottratta alla VM tramite Balloon Driver, questa quantità non è inclusa nella Concessa e nel Consumato.
Alti valori di Granted e Consumed sono perfettamente normali. Il sistema operativo sottrae gradualmente la memoria dall'iper-vip e non la restituisce. Col passare del tempo, per una VM attivamente in funzione, i valori di questi contatori si avvicinano alla memoria configurata e rimangono lì.
Zero — la quantità di memoria RAM della VM (KB) che contiene zeri. Questa memoria è considerata libera dall'iper-vip e può essere data a altre macchine virtuali. Una volta che il sistema operativo ospite ha scritto qualcosa nella memoria azzerata, essa passa a Consumed e non ritorna più.
Reserved Overhead — la quantità di memoria RAM della VM (KB) riservata dall'iper-vip per il funzionamento della VM. È un volume ridotto, ma deve necessariamente essere disponibile sull'host, altrimenti la VM non si avvierà.
Balloon — la quantità di memoria RAM (KB) sottratta alla VM tramite il Balloon Driver.
Compressed — la quantità di memoria RAM (KB) che è stata ridotta.
Swapped — la quantità di memoria RAM (KB) che, in mancanza di memoria fisica sul server, è stata spostata su disco.
I contatori di Balloon e delle altre tecniche di recupero della memoria sono pari a zero.
Ecco come appare il grafico con i contatori della memoria di una VM funzionante con 150 GB di RAM.
Nel grafico sottostante, la VM presenta evidenti problemi. Si può osservare che per questa VM sono state utilizzate tutte le tecniche descritte per la gestione della memoria. Il Balloon per questa VM è notevolmente più grande rispetto al Consumed. Di fatto, la VM è più morta che viva.
ESXTOP
Come per la CPU, se vogliamo valutare rapidamente la situazione sull'host, così come la sua dinamica con intervalli di 2 secondi, è utile utilizzare ESXTOP.
Lo schermo di ESXTOP per la memoria si attiva premendo il tasto «m» e appare come segue (campi selezionati: B, D, H, J, K, L, O):
I seguenti parametri saranno interessanti per noi:
Mem overcommit avg — valore medio del sovrascritto di memoria sull'host negli ultimi 1, 5 e 15 minuti. Se è superiore a zero, è un motivo per controllare cosa sta succedendo, ma non sempre è indicativo di problemi.
Nelle righe PMEM/MB e VMKMEM/MB — informazioni sulla memoria fisica del server e sulla memoria disponibile per il VMkernel. Qui è interessante vedere il valore di minfree (in MB) e lo stato della memoria dell'host (nel nostro caso, alto).
Nella riga NUMA/MB è possibile vedere la distribuzione della memoria RAM tra i nodi NUMA (socket). In questo esempio, la distribuzione è irregolare, il che non è proprio ideale.
Di seguito ci sono le statistiche generali del server relative alle tecniche di recupero della memoria:
PSHARE/MB — queste sono le statistiche TPS;
SWAP/MB — statistiche sull'uso dello Swap;
ZIP/MB — statistiche sulla compressione delle pagine di memoria;
MEMCTL/MB — statistiche sull'uso del Balloon Driver.
Per singole VM, possiamo essere interessati alle seguenti informazioni. Ho nascosto i nomi delle VM per non confondere il pubblico:). Se la metrica ESXTOP è analoga al contatore in vSphere, riporto il contatore corrispondente.
MEMSZ — quantità di memoria configurata sulla VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
GRANT — Granted in MB.
TCHD — Active in MB.
MCTL? — se è stato installato il Balloon Driver sulla VM.
MCTLSZ — Balloon in MB.
MCTLGT — quantità di memoria RAM (MB) che ESXi desidera prelevare dalla VM tramite il Balloon Driver (Memctl Target).
MCTLMAX — quantità massima di memoria RAM (MB) che ESXi può prelevare dalla VM tramite il Balloon Driver.
SWCUR — quantità attuale di memoria RAM (MB) fornita alla VM dal file di Swap.
SWGT — quantità di memoria RAM (MB) che ESXi desidera fornire alla VM dal file di Swap (Swap Target).
Anche tramite ESXTOP è possibile visualizzare informazioni più dettagliate sulla topologia NUMA delle VM. Per fare ciò, è necessario selezionare i campi D,G:
NHN – nodi NUMA su cui è posizionata la VM. Qui si possono subito notare le VM wide che non rientrano in un singolo nodo NUMA.
NRMEM – quanti megabyte di memoria la VM utilizza da un nodo NUMA remoto.
NLMEM – quanti megabyte di memoria la VM utilizza da un nodo NUMA locale.
N%L – percentuale di memoria della VM sul nodo NUMA locale (se inferiore all'80% — potrebbero sorgere problemi di prestazioni).
Memoria sull'ipervisore
Se i contatori CPU sull'ipervisore di solito non presentano particolare interesse, la situazione è diversa per la memoria. Un alto utilizzo della memoria sulla VM non indica sempre un problema di prestazioni, mentre un alto utilizzo della memoria sull'ipervisore avvia le tecniche di gestione della memoria e causa problemi di prestazioni per la VM. È importante monitorare gli allarmi sull'Host Memory Usage e prevenire che la VM entri nello Swap.
Unswa
Se una VM finisce nello Swap, le sue prestazioni diminuiscono notevolmente. I segni del Ballooning e della compressione scompaiono rapidamente dopo che la memoria RAM libera è disponibile sull'host, mentre il ritorno dalla Swap alla memoria RAM del server non avviene altrettanto rapidamente per la macchina virtuale.
Fino alla versione ESXi 6.0, l'unico modo sicuro e veloce per uscire una VM dallo Swap era il riavvio (più precisamente, lo spegnimento e accensione del contenitore). A partire da ESXi 6.0, è stato introdotto un metodo, seppur non ufficiale, ma funzionante e affidabile per rimuovere la VM dallo Swap. Durante una delle conferenze, ho avuto l'opportunità di discutere con uno degli ingegneri di VMware responsabile del CPU Scheduler. Ha confermato che il metodo è effettivamente funzionante e sicuro. Nella nostra esperienza, non abbiamo riscontrato problemi con esso.
Comandi per rimuovere una VM dallo Swap Duncan Epping. Non ripeterò la descrizione dettagliata, ma fornirò un esempio del suo utilizzo. Come si può vedere nello screenshot, dopo un certo periodo dall'esecuzione del comando, la Swap sulla VM scompare.
Consigli per la gestione della memoria RAM su ESXi
Infine, ecco alcuni consigli per aiutarvi a evitare problemi di prestazioni delle VM legati alla memoria RAM:
- Evitare la sovrascrittura della memoria RAM nei cluster di produzione. È consigliabile mantenere sempre circa il 20-30% di memoria libera nel cluster, in modo che DRS (e l'amministratore) abbia spazio per manovrare e che durante la migrazione delle VM non finiscano in Swap. Non dimenticate di riservare spazio per la tolleranza ai guasti. È sgradevole quando, a causa di un server guasto e al riavvio delle VM tramite HA, parte delle macchine finisce in Swap.
- Nelle infrastrutture ad alta consolidazione, evitate di creare VM con memoria superiore alla metà della memoria dell'host. Anche questo aiuterà DRS a distribuire senza problemi le macchine virtuali tra i server del cluster. Questa regola, ovviamente, non è universale :),
- Controllate l'allerta sull'uso della memoria dell'host.
- Non dimenticate di installare VMware Tools sulle VM e di non disabilitare il Ballooning.
- Valutate la possibilità di abilitare l'Inter-VM TPS e disabilitare le Large Pages in ambienti VDI e ambienti di test.
- Se la VM ha problemi di prestazioni, verificate se sta utilizzando memoria da un nodo NUMA remoto.
- Estrai la VM da Swap il prima possibile! Oltre a tutto, se la VM è in Swap, per ovvi motivi ne risente lo storage.
Questo è tutto sulla memoria RAM per ora. Di seguito ci sono articoli sull'argomento per coloro che vogliono approfondire i dettagli. Il prossimo articolo sarà dedicato allo storage.
Link utili
Fonte: habr.com
