In questo articolo parleremo dei contatori delle prestazioni della memoria RAM in vSphere.
Sembra che la questione della memoria sia più chiara rispetto a quella del processore: se ci sono problemi di prestazioni nelle VM, è difficile non notarli. Tuttavia, una volta che compaiono, affrontarli diventa molto più complesso. 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 del server non è sufficiente per tutti gli utenti, ESXi inizia a utilizzare tecniche di ottimizzazione del consumo di memoria (memory reclamation techniques). Altrimenti, i sistemi operativi delle VM andrebbero in crash per errori di accesso alla RAM.
Quali tecniche applicare ESXi decide in base al carico di memoria:
Stato della memoria
Limite
Azioni
High
400% di minFree
Dopo aver raggiunto il limite superiore, le grandi pagine di memoria vengono suddivise in pagine più piccole (TPS opera in modalità standard).
Cancella
100% di minFree
Le grandi pagine di memoria vengono suddivise in pagine più piccole, TPS funziona forzatamente.
Soft
64% di minFree
TPS + Balloon
Hard
32% di minFree
TPS + Compress + Swap
Basso
16% di minFree
Compress + Swap + Block
minFree è la memoria RAM necessaria per il funzionamento dell'iperfvisor.
Fino alla versione ESXi 4.1 inclusa, minFree era di default fisso: 6% della memoria RAM del server (la percentuale poteva essere cambiata tramite l'opzione Mem.MinFreePct su ESXi). Nelle versioni successive, a causa dell'aumento dei volumi di memoria sui server, minFree è stato calcolato in base alla quantità di memoria dell'host, anziché come valore fisso percentuale.
Il valore di minFree (di default) viene calcolato come segue:
Percentuale di memoria riservata per minFree
Intervallo di memoria
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Memoria residua
Ad esempio, per un server con 128 GB di RAM, il valore di MinFree sarà il seguente:
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 residua (100 GB)
1024 MB
Di solito, solo lo stato High può essere considerato normale per i banchi di lavoro produttivi. Per i banchi destinati ai test e allo sviluppo sono accettabili gli stati Clear/Soft. Se la memoria RAM sull'host scende al di sotto del 64% di MinFree, le macchine virtuali in esecuzione su di esso presentano sicuramente problemi di prestazioni.
In ogni stato vengono utilizzate tecniche di recupero della memoria specifiche, a partire dal TPS, che ha praticamente un impatto nullo sulle prestazioni delle VM, fino allo Swapping. Ti parlerò di loro in modo più dettagliato.
Condivisione di Pagine Trasparenti (TPS). Il TPS è, in parole povere, la deduplicazione delle pagine di RAM delle macchine virtuali sul server.
ESXi cerca le pagine di RAM identiche delle macchine virtuali, calcolando e confrontando gli 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 pagine di memoria di dimensione 4 KB (pagine piccole). Le pagine di dimensioni 2 MB (pagine grandi) non vengono nemmeno tentate di essere deduplicate dal hypervisor: la possibilità di trovare pagine identiche di tale dimensione è bassa.
Per impostazione predefinita, ESXi assegna la memoria alle grandi pagine. La suddivisione delle grandi pagine in piccole inizia al raggiungimento della soglia dello stato High e avviene in modo forzato quando si raggiunge lo stato Clear (vedi tabella degli stati dell'hypervisor).
Se desideri che il TPS inizi a funzionare senza attendere che la RAM dell'host sia piena, devi impostare il valore in Advanced Options di ESXi “Mem.AllocGuestLargePage” a 0 (valore predefinito 1). In questo modo, l'allocazione delle grandi pagine di memoria per le macchine virtuali sarà disabilitata.
Da dicembre 2014, in tutte le versioni di ESXi, il TPS tra VM è disabilitato per impostazione predefinita, poiché è stata trovata una vulnerabilità che permette teoricamente di accedere alla RAM di un'altra VM. Maggiori dettagli qui. Non ho trovato informazioni sulla concreta implementazione della vulnerabilità TPS.
La politica TPS è controllata tramite l'opzione avanzata “Mem.ShareForceSalting” su ESXi:
0 — TPS Inter-VM. Il TPS funziona per le pagine di VM diverse;
1 – TPS per VM con lo stesso valore “sched.mem.pshare.salt” in VMX;
2 (valore predefinito) – TPS Intra-VM. Il TPS funziona per le pagine all'interno di una VM.
È sicuramente sensato disabilitare le pagine di grandi dimensioni e abilitare l'Inter-VM TPS sui banchi di prova. Questo può anche essere utilizzato per banchi con un gran numero di VMs simili. Ad esempio, sui banchi 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 delle VMs, come lo è il TPS. Ma se usato correttamente, si può convivere e persino lavorare con il Ballooning.
Insieme ai Vmware Tools, sulla VM viene installato un driver speciale chiamato Balloon Driver (o vmmemctl). Quando l'ipervisore inizia ad esaurire la memoria fisica e passa allo stato Soft, ESXi richiede alla VM di restituire la memoria operativa non utilizzata tramite questo Balloon Driver. Il driver, a sua volta, opera a livello di sistema operativo e richiede memoria libera a quest'ultimo. L'ipervisore vede quali pagine di memoria fisica sono occupate dal Balloon Driver, preleva memoria dalla macchina virtuale e la restituisce all'host. Non si verificano problemi con il funzionamento del SO, poiché a livello di SO la memoria è occupata dal Balloon Driver. Di default, il Balloon Driver può prelevare fino al 65% della memoria della VM.
Se sulla VM non sono installati VMware Tools o se il Ballooning è disabilitato (non lo consiglio, ma esiste :), l'ipervisore passa subito a tecniche più aggressive per il recupero della memoria. Conclusione: assicurati che i VMware Tools siano installati sulla VM.
È possibile controllare il funzionamento del Balloon Driver dal SO tramite i VMware Tools..
Memory Compression. Questa tecnica viene utilizzata quando ESXi raggiunge lo stato Hard. Come indica il nome, ESXi cerca di comprimere pagine di memoria operativa da 4 KByte a 2 KByte, liberando così un po' di spazio nella memoria fisica del server. Questa tecnica aumenta significativamente il tempo di accesso al contenuto delle pagine di memoria operativa della VM, poiché la pagina deve essere decompressa. A volte non tutte le pagine possono essere compresse e il processo stesso richiede un certo tempo. Pertanto, questa tecnica in pratica non è molto efficace.
Memory Swapping. Dopo una breve fase di Compressione della Memoria, ESXi passa praticamente inevitabilmente (se le VMs non sono migrate su altri host o spente) allo Swapping. E se rimane pochissima memoria (stato Low), l'ipervisore smette anche di assegnare pagine di memoria alle VMs, il che può causare problemi nei sistemi operativi guest delle VMs.
Ecco come funziona lo Swapping. Quando viene avviata la macchina virtuale, viene creato un file con estensione .vswp. La sua dimensione è pari alla memoria volatile non riservata della VM: è la differenza tra la memoria configurata e quella riservata. Durante il funzionamento dello Swapping, ESXi scarica le pagine di memoria della macchina virtuale in questo file e inizia a lavorare con esso anziché con la memoria fisica del server. Naturalmente, tale "memoria" è molto più lenta rispetto a quella reale, anche se il file .vswp si trova su uno storage veloce.
A differenza del Ballooning, quando alla VM vengono sottratte pagine non utilizzate, nello Swapping le pagine che potrebbero essere attivamente utilizzate dal sistema operativo o dalle applicazioni all'interno della VM possono essere spostate sul disco. Di conseguenza, le prestazioni della VM possono diminuire fino al blocco totale. La VM funziona formalmente e può essere disattivata correttamente dal sistema operativo, se si ha pazienza 😉
Se una VM è finita nello Swap, si tratta di una situazione anomala che sarebbe meglio evitare.
Le principali metriche delle prestazioni della memoria della macchina virtuale
E siamo arrivati al punto centrale. Per monitorare lo stato della memoria nella VM ci sono le seguenti metriche:
Attivo — mostra la quantità di memoria volatile (KB) a cui la VM ha avuto accesso nel periodo di misurazione precedente.
Utilizzo — è lo stesso di Attivo, ma in percentuale rispetto alla memoria volatile configurata della VM. Si calcola con la seguente formula: attivo ÷ dimensione della memoria configurata della macchina virtuale.
Un alto Utilizzo e Attivo, rispettivamente, non è sempre indicativo di problemi di prestazioni della VM. Se la VM utilizza la memoria in modo aggressivo (almeno, accede ad essa), non significa che ci sia carenza di memoria. Piuttosto, è un motivo per verificare cosa sta succedendo nel sistema operativo.
C'è un allarme standard per l'Utilizzo della Memoria per la VM:
Shared — quantità di memoria volatile della VM, de-duplicata tramite TPS (all'interno della VM o tra VM).
Concesso — quantità di memoria fisica dell'host (KB) che è stata concessa alla VM. Include la memoria Condivisa.
Consumato (Concesso — Condiviso) — quantità di memoria fisica (KB) che la VM consuma dall'host. Non include la memoria Condivisa.
Se una parte della memoria della VM viene concessa non dalla memoria fisica dell'host, ma da un file di swap o se la memoria è stata sottratta dalla VM tramite il Balloon Driver, questa quantità non viene conteggiata nei valori Concesso e Consumato.
Valori elevati di Granted e Consumed sono del tutto normali. Il sistema operativo preleva gradualmente la memoria dall'hypervisor e non la restituisce. Col tempo, per una VM attivamente operante, i valori di questi contatori si avvicinano alla quantità di memoria configurata, e rimangono lì.
Zero — quantità di memoria RAM della VM (Kbyte) che contiene zeri. Questa memoria è considerata libera dall'hypervisor e può essere assegnata ad altre macchine virtuali. Dopo che il sistema operativo guest ha scritto qualcosa nella memoria azzerata, passa a Consumed e non può essere restituita.
Riserva di sovraccarico — quantità di memoria RAM della VM (Kbyte) riservata dall'hypervisor per il funzionamento della VM. Questa è una piccola quantità, ma deve essere necessariamente disponibile sull'host, altrimenti la VM non si avvia.
Balloon — quantità di memoria RAM (Kbyte) prelevata dalla VM tramite Balloon Driver.
Compresso — quantità di memoria RAM (Kbyte) che è stata compressa.
Scambiata — quantità di memoria RAM (Kbyte) che, in assenza di memoria fisica sul server, è stata trasferita su disco.
Balloon e gli altri contatori delle tecniche di recupero della memoria sono pari a zero.
Ecco come appare un grafico con i contatori di una VM che funziona normalmente con 150 GB di RAM.
Nel grafico sottostante, la VM presenta evidenti problemi. Sotto il grafico si può vedere che per questa VM sono state utilizzate tutte le tecniche descritte per la gestione della memoria. Balloon per questa VM è significativamente più grande di Consumed. In realtà, la VM è più morta che viva.
ESXTOP
Come per la CPU, se vogliamo valutare rapidamente la situazione sull'host e la sua dinamica con intervalli fino a 2 secondi, vale la pena utilizzare ESXTOP.
Lo schermo di ESXTOP per la memoria si attiva con il tasto «m» e appare come segue (sono stati selezionati i campi B,D,H,J,K,L,O):
I seguenti parametri saranno interessanti per noi:
Mem overcommit avg — valore medio di overcommit della memoria sull'host negli ultimi 1, 5 e 15 minuti. Se è superiore a zero, è un motivo per esaminare cosa sta succedendo, ma non è sempre un indicatore di problemi.
Nelle righe PMEM/MB e VMKMEM/MB — informazioni sulla memoria fisica del server e sulla memoria disponibile per il VMkernel. Di interessante qui si può vedere il valore minfree (in MByte), lo stato della memoria dell'host (nel nostro caso, alto).
Nella riga NUMA/MB si può vedere la distribuzione della memoria RAM sulle nodi NUMA (socket). In questo esempio la distribuzione è irregolare, il che non è molto positivo.
Di seguito sono statistiche generali sul server per le tecniche di recupero della memoria:
PSHARE/MB — è la statistica TPS;
SWAP/MB — statistica sull'utilizzo dello Swap;
ZIP/MB — statistica sulla compressione delle pagine di memoria;
MEMCTL/MB — statistica sull'utilizzo del Balloon Driver.
Per singole VM, potrebbe interessarci la seguente informazione. 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 — volume di memoria configurato sulla VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
GRANT — Granted in MB.
TCHD — Active in MB.
MCTL? — se sulla VM è stato installato il Balloon Driver.
MCTLSZ — Balloon in MB.
MCTLGT — volume di memoria RAM (MB) che ESXi desidera sottrarre alla VM tramite il Balloon Driver (Memctl Target).
MCTLMAX — volume massimo di memoria RAM (MB) che ESXi può sottrarre alla VM tramite il Balloon Driver.
SWCUR — volume attuale di memoria RAM (MB) ceduto alla VM dal file di Swap.
SWGT — volume di memoria RAM (MB) che ESXi desidera cedere alla VM dal file di Swap (Swap Target).
Attraverso ESXTOP è possibile visualizzare informazioni più dettagliate sulla topologia NUMA della VM. Per farlo, è necessario selezionare i campi D,G:
NHN – nodi NUMA su cui si trova la VM. Qui è possibile notare subito wide vm che non si adattano a un singolo nodo NUMA.
NRMEM – quanti megabyte di memoria la VM preleva da un nodo NUMA remoto.
NLMEM – quanti megabyte di memoria la VM preleva da un nodo NUMA locale.
N%L – percentuale di memoria della VM sul nodo NUMA locale (se meno dell'80% — potrebbero sorgere problemi di prestazioni).
Memoria sull'ipervisor
Se i contatori CPU sull'ipervisor generalmente non suscitano particolare interesse, la situazione con la memoria è opposta. Un Alto Utilizzo della Memoria sulla VM non indica sempre un problema di prestazioni, mentre l'Alto Utilizzo della Memoria sull'ipervisor avvia tecniche di gestione della memoria e causa problemi di prestazioni sulla VM. È necessario monitorare gli allarmi sull'Utilizzo della Memoria dell'Host e prevenire l'ingresso della VM nello Swap.
Unswap
Se la VM è finita nello Swap, le sue prestazioni diminuiscono notevolmente. I segni del Ballooning e della compressione svaniscono rapidamente dopo che la memoria RAM è tornata disponibile sull'host, mentre la macchina virtuale non si affretta a tornare dalla Swap alla memoria RAM del server.
Fino alla versione ESXi 6.0, l'unico modo affidabile e veloce per estrarre le VM dallo Swap era il riavvio (se preciso, lo spegnimento/accensione del contenitore). A partire da ESXi 6.0 è emerso un metodo, seppur non ufficiale, ma funzionante e affidabile per estrarre le VM dallo Swap. In una delle conferenze sono riuscito a parlare con uno degli ingegneri di VMware, responsabile del CPU Scheduler. Ha confermato che il metodo è sicuramente funzionante e sicuro. Nel nostro esperienza non abbiamo riscontrato problemi con esso.
Comandi per estrarre la 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 po' di tempo dall'esecuzione del comando indicato, lo Swap sulla VM scompare.
Consigli per la gestione della memoria operativa su ESXi
Per concludere, ecco alcuni consigli che possono aiutarti a evitare problemi di prestazioni delle VM a causa della memoria operativa:
- Evita la sovrascrittura della memoria operativa nei cluster produttivi. È consigliabile avere sempre circa il 20-30% di memoria libera nel cluster, affinché il DRS (e l'amministratore) abbiano margine di manovra, e affinché durante la migrazione delle VM non vadano in Swap. Non dimenticare di considerare un margine per la tolleranza ai guasti. È spiacevole quando, a causa del malfunzionamento di un server e del riavvio delle VM tramite HA, parte delle macchine va anche in Swap.
- Nelle infrastrutture ad alta consolidazione, cerca di NON creare VM con una memoria superiore a metà della memoria dell'host. Questo aiuterà nuovamente il DRS a distribuire le macchine virtuali tra i server del cluster senza problemi. Questa regola, ovviamente, non è universale :)
- Fai attenzione all'allerta di utilizzo della memoria dell'host.
- Non dimenticare di installare VMware Tools sulle VM e di non disattivare il Ballooning.
- Valuta la possibilità di attivare l'Inter-VM TPS e disattivare le Large Pages in ambienti con VDI e di test.
- Se la VM ha problemi di prestazioni, verifica se sta utilizzando memoria da un nodo NUMA remoto.
- Estrai la VM dallo Swap il più rapidamente possibile! Oltre tutto, se la VM è nello Swap, per ovvi motivi soffre l'archiviazione.
Questo è tutto riguardo alla memoria operativa. Di seguito troverai articoli sull'argomento per chi desidera approfondire. Il prossimo articolo sarà dedicato allo storage.
Link utili
Fonte: habr.com
