In questo articolo parleremo dei contatori delle prestazioni della memoria ad accesso casuale (RAM) in vSphere.
Sembra che con la memoria sia tutto più chiaro che con il processore: se una VM ha problemi di prestazioni, è difficile non notarli. Ma se compaiono, è molto più difficile affrontarli. Ma prima le cose principali.
Un po 'di teoria
La RAM delle macchine virtuali viene prelevata dalla memoria del server su cui sono in esecuzione le macchine virtuali. È abbastanza ovvio :). Se la RAM del server non è sufficiente per tutti, ESXi inizia a utilizzare tecniche di recupero della memoria per ottimizzare il consumo di RAM. In caso contrario, i sistemi operativi delle VM andrebbero in crash con errori di accesso alla RAM.
Quali tecniche utilizzare ESXi decide in base al carico di RAM:
Stato della memoria
Confine
Attività
Alta
400% di minGratis
Dopo aver raggiunto il limite superiore, le pagine di memoria di grandi dimensioni vengono suddivise in pagine piccole (TPS funziona in modalità standard).
Cancellare
100% di minGratis
Le grandi pagine di memoria sono suddivise in piccole, TPS è costretto a funzionare.
Soft
64% di minGratis
TPS + Palloncino
Hard
32% di minGratis
TPS + Comprimi + Scambia
Basso
16% di minGratis
Comprimi + Scambia + Blocca
minFree è la RAM necessaria per il funzionamento dell'hypervisor.
Prima di ESXi 4.1 incluso, minFree era corretto per impostazione predefinita: 6% della RAM del server (la percentuale poteva essere modificata tramite l'opzione Mem.MinFreePct su ESXi). Nelle versioni successive, a causa dell'aumento delle dimensioni della memoria sui server, minFree ha iniziato a essere calcolato in base alla quantità di memoria dell'host e non come percentuale fissa.
Il valore minFree (predefinito) viene calcolato come segue:
Percentuale di memoria riservata per minFree
Gamma di memoria
6%
0-4GB
4%
4-12GB
2%
12-28GB
1%
Memoria residua
Ad esempio, per un server con 128 GB di RAM, il valore MinFree sarebbe:
Minimo libero = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Il valore effettivo può differire di un paio di centinaia di MB, dipende dal server e dalla RAM.
Percentuale di memoria riservata per minFree
Gamma di memoria
Valore per 128 GB
6%
0-4GB
245,76 MB
4%
4-12GB
327,68 MB
2%
12-28GB
327,68 MB
1%
Memoria rimanente (100 GB)
1024 MB
Solitamente, per i popolamenti produttivi, solo lo stato Alto può essere considerato normale. Per i banchi di test e sviluppo, gli stati Clear/Soft possono essere accettabili. Se la RAM sull'host è inferiore al 64% di MinFree, le macchine virtuali in esecuzione su di esso presentano sicuramente problemi di prestazioni.
In ogni stato vengono applicate determinate tecniche di recupero della memoria, a partire dal TPS, che praticamente non influisce sulle prestazioni della VM, e termina con lo scambio. Ti dirò di più su di loro.
Condivisione trasparente della pagina (TPS). TPS è, in parole povere, la deduplicazione delle pagine di memoria della macchina virtuale su un server.
ESXi cerca le pagine identiche della RAM della macchina virtuale contando e confrontando la somma hash delle pagine e rimuove le pagine duplicate, sostituendole con collegamenti alla stessa pagina nella memoria fisica del server. Di conseguenza, il consumo di memoria fisica è ridotto ed è possibile ottenere una sottoscrizione eccessiva della memoria con un degrado minimo o nullo delle prestazioni.
Questo meccanismo funziona solo per pagine di memoria da 4 KB (pagine piccole). L'hypervisor non tenta nemmeno di deduplicare pagine di 2 MB (pagine grandi): la possibilità di trovare pagine identiche di queste dimensioni non è grande.
Per impostazione predefinita, ESXi assegna memoria a pagine di grandi dimensioni. La suddivisione di pagine grandi in pagine piccole inizia quando viene raggiunta la soglia dello stato Alto e viene forzata quando viene raggiunto lo stato Cancella (vedere la tabella dello stato dell'hypervisor).
Se si desidera che TPS inizi a funzionare senza attendere che la RAM dell'host si riempia, in Opzioni avanzate ESXi è necessario impostare il valore "Mem.AllocGuestLargePage" a 0 (predefinito 1). Quindi l'allocazione di pagine di memoria di grandi dimensioni per le macchine virtuali verrà disabilitata.
Da dicembre 2014, in tutte le release di ESXi, il TPS tra VM è stato disabilitato per impostazione predefinita, in quanto è stata rilevata una vulnerabilità che teoricamente consente l'accesso da una VM alla RAM di un'altra VM. Dettagli qui. Non ho trovato informazioni sull'implementazione pratica dello sfruttamento della vulnerabilità TPS.
Politica TPS controllata tramite l'opzione avanzata "Mem.ShareForceSalting" su ESXi:
0 - TPS inter-VM. TPS funziona per pagine di macchine virtuali diverse;
1 – TPS per VM con lo stesso valore “sched.mem.pshare.salt” in VMX;
2 (impostazione predefinita) - TPS intra-VM. TPS funziona per le pagine all'interno della VM.
Ha decisamente senso disattivare le pagine di grandi dimensioni e attivare il TPS Inter-VM sui banchi di prova. Può essere utilizzato anche per stand con un numero elevato dello stesso tipo di VM. Ad esempio, sugli stand con VDI, il risparmio nella memoria fisica può raggiungere decine di percento.
memoria in mongolfiera. Il ballooning non è più una tecnica così innocua e trasparente per il sistema operativo VM come TPS. Ma con una corretta applicazione, puoi vivere e persino lavorare con Ballooning.
Insieme a Vmware Tools, sulla VM viene installato un driver speciale chiamato Balloon Driver (noto anche come vmmemctl). Quando l'hypervisor inizia a esaurire la memoria fisica ed entra nello stato Soft, ESXi chiede alla VM di recuperare la RAM inutilizzata tramite questo Balloon Driver. Il driver, a sua volta, lavora a livello di sistema operativo e richiede memoria libera da esso. L'hypervisor vede quali pagine di memoria fisica sono state occupate dal Balloon Driver, preleva la memoria dalla macchina virtuale e la restituisce all'host. Non ci sono problemi con il funzionamento del sistema operativo, poiché a livello di sistema operativo la memoria è occupata dal Balloon Driver. Per impostazione predefinita, Balloon Driver può occupare fino al 65% della memoria della VM.
Se VMware Tools non è installato sulla VM o Ballooning è disabilitato (non lo consiglio, ma ci sono :), l'hypervisor passa immediatamente a tecniche di rimozione della memoria più rigorose. Conclusione: assicurati che VMware Tools sia sulla VM.
Il funzionamento di Balloon Driver può essere controllato dal sistema operativo tramite VMware Tools.
compressione della memoria. Questa tecnica viene utilizzata quando ESXi raggiunge lo stato Hard. Come suggerisce il nome, ESXi tenta di ridurre una pagina di 4 KB di RAM in 2 KB e quindi di liberare spazio nella memoria fisica del server. Questa tecnica aumenta notevolmente il tempo di accesso al contenuto delle pagine RAM della VM, poiché la pagina deve essere prima decompressa. A volte non tutte le pagine possono essere compresse e il processo stesso richiede del tempo. Pertanto, questa tecnica non è molto efficace nella pratica.
scambio di memoria. Dopo una breve fase di Memory Compression, ESXi quasi inevitabilmente (se le VM non sono partite per altri host o si sono spente) passerà allo Swapping. E se è rimasta pochissima memoria (stato basso), l'hypervisor interrompe anche l'allocazione di pagine di memoria alla VM, il che può causare problemi nel sistema operativo guest della VM.
Ecco come funziona lo scambio. Quando accendi una macchina virtuale, viene creato un file con estensione .vswp. Ha le stesse dimensioni della RAM non riservata della VM: è la differenza tra la memoria configurata e quella riservata. Quando Swapping è in esecuzione, 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 "operativa" è di diversi ordini di grandezza più lenta di quella reale, anche se .vswp si trova su una memoria veloce.
A differenza del Ballooning, quando le pagine inutilizzate vengono prelevate dalla VM, con lo Swapping, le pagine utilizzate attivamente dal sistema operativo o dalle applicazioni all'interno della VM possono essere spostate su disco. Di conseguenza, le prestazioni della VM scendono fino al punto di congelamento. La VM funziona formalmente e almeno può essere correttamente disabilitata dal sistema operativo. Se hai pazienza 😉
Se le VM sono andate in Swap, questa è una situazione anomala, che è meglio evitare se possibile.
Contatori chiave delle prestazioni della memoria della macchina virtuale
Quindi siamo arrivati al punto principale. Per monitorare lo stato della memoria nella VM, sono disponibili i seguenti contatori:
Attivo — mostra la quantità di RAM (KB) a cui la VM ha avuto accesso nel periodo di misurazione precedente.
Impiego - come Attivo, ma come percentuale della RAM configurata della VM. Calcolato utilizzando la seguente formula: dimensione di memoria attiva ÷ macchina virtuale configurata.
Utilizzo elevato e Attivo, rispettivamente, non sono sempre un indicatore di problemi di prestazioni della macchina virtuale. Se la VM utilizza in modo aggressivo la memoria (almeno vi accede), ciò non significa che non ci sia memoria sufficiente. Piuttosto, è un'occasione per vedere cosa sta succedendo nel sistema operativo.
Esiste un allarme di utilizzo della memoria standard per le macchine virtuali:
diviso - la quantità di RAM della VM deduplicata utilizzando TPS (all'interno della VM o tra le VM).
Concesso - la quantità di memoria host fisica (KB) assegnata alla VM. Include Condiviso.
consumato (Concesso - Condiviso): la quantità di memoria fisica (KB) consumata dalla VM dall'host. Non include Condiviso.
Se parte della memoria della VM è fornita non dalla memoria fisica dell'host, ma dal file di scambio, oppure la memoria è prelevata dalla VM attraverso il Balloon Driver, questa quantità non viene presa in considerazione in Concessa e Consumata.
I valori Concessi e Consumati alti sono perfettamente normali. Il sistema operativo prende gradualmente memoria dall'hypervisor e non la restituisce. Nel tempo, in una VM in esecuzione attiva, i valori di questi contatori si avvicinano alla quantità di memoria configurata e vi rimangono.
Zero — la quantità di VM RAM (KB), che contiene zeri. Tale memoria è considerata libera dall'hypervisor e può essere ceduta ad altre macchine virtuali. Dopo che il sistema operativo guest ha scritto qualcosa nella memoria azzerata, entra in Consumed e non torna indietro.
Spese generali riservate — la quantità di RAM della VM, (KB) riservata dall'hypervisor per il funzionamento della VM. Questa è una piccola quantità, ma deve essere disponibile sull'host, altrimenti la VM non si avvierà.
Palloncino — la quantità di RAM (KB) sequestrata dalla VM utilizzando il Balloon Driver.
compressa - la quantità di RAM (KB) che è stata compressa.
scambiato - la quantità di RAM (KB) che, per mancanza di memoria fisica sul server, è stata trasferita su disco.
I contatori del fumetto e di altre tecniche di recupero della memoria sono pari a zero.
Ecco come appare il grafico con i contatori di memoria per una VM normalmente funzionante con 150 GB di RAM.
Nel grafico sottostante, la VM presenta evidenti problemi. Sotto il grafico, puoi vedere che per questa VM sono state utilizzate tutte le tecniche descritte per lavorare con la RAM. Il fumetto per questa VM è molto più grande di Consumato. In effetti, il VM è più morto che vivo.
ESXTOP
Come per la CPU, se vogliamo valutare rapidamente la situazione sull'host, nonché le sue dinamiche con un intervallo fino a 2 secondi, dovremmo utilizzare ESXTOP.
La schermata ESXTOP da Memory viene richiamata con il tasto "m" e si presenta così (i campi B, D, H, J, K, L, O sono selezionati):
I seguenti parametri saranno di nostro interesse:
Mem overcommit avg - il valore medio di oversubscription di memoria sull'host per 1, 5 e 15 minuti. Se è superiore allo zero, questa è un'occasione per vedere cosa sta succedendo, ma non sempre un indicatore di problemi.
A righe PMEM/MB и VMKEM/MB - informazioni sulla memoria fisica del server e sulla memoria disponibile per VMkernel. Dall'interessante qui puoi vedere il valore di minfree (in MB), lo stato dell'host in memoria (nel nostro caso alto).
In linea NUMA/MB puoi vedere la distribuzione della RAM per nodi NUMA (socket). In questo esempio, la distribuzione non è uniforme, il che, in linea di principio, non è molto buona.
Di seguito sono riportate le statistiche generali del server sulle tecniche di recupero della memoria:
PSHARE/MB sono statistiche TPS;
SCAMBIA/MB — Statistiche sull'utilizzo dello scambio;
CAP/MB — statistiche sulla compressione delle pagine di memoria;
MEMCTL/MB — Statistiche sull'utilizzo di Balloon Driver.
Per le singole VM, potremmo essere interessati alle seguenti informazioni. Ho nascosto i nomi delle VM per non confondere il pubblico :). Se la metrica ESXTOP è simile al contatore in vSphere, fornisco il contatore corrispondente.
MEMSZ — la quantità di memoria configurata sulla VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + intatto.
GRANT — Concesso a MB.
TCHD — Attivo in MB.
MCTL? - se Balloon Driver è installato sulla VM.
MCTLSZ — Mongolfiera a MB.
MCTLGT — la quantità di RAM (MB) che ESXi desidera prelevare dalla VM tramite Balloon Driver (Memctl Target).
MCTLMAX - la quantità massima di RAM (MB) che ESXi può prelevare dalla VM attraverso il Balloon Driver.
SWCUR — la quantità corrente di RAM (MB) assegnata alla VM dal file di scambio.
S.W.G.T. - la quantità di RAM (MB) che ESXi vuole dare alla VM dal file Swap (Swap Target).
Inoltre, tramite ESXTOP, è possibile visualizzare informazioni più dettagliate sulla topologia NUMA della VM. Per fare ciò selezionare i campi D, G:
PICCOLO – Nodi NUMA su cui si trova la VM. Qui puoi immediatamente notare vm larghi, che non si adattano a un nodo NUMA.
NRMEM - quanti megabyte di memoria la VM prende dal nodo NUMA remoto.
NLMEM - quanti megabyte di memoria la VM prende dal nodo NUMA locale.
N%L – percentuale di memoria VM sul nodo NUMA locale (se inferiore all'80%, potrebbero verificarsi problemi di prestazioni).
Memoria sull'hypervisor
Se i contatori della CPU per l'hypervisor di solito non sono di particolare interesse, allora la situazione è invertita con la memoria. L'utilizzo elevato della memoria su una macchina virtuale non indica sempre un problema di prestazioni, ma un utilizzo elevato della memoria su un hypervisor attiva le tecniche di gestione della memoria e causa problemi di prestazioni nella macchina virtuale. Gli allarmi di utilizzo della memoria dell'host devono essere monitorati per evitare che la VM entri in Swap.
Annulla scambio
Se una VM è in Swap, le sue prestazioni sono notevolmente ridotte. Tracce di Ballooning e compressione scompaiono rapidamente dopo che la RAM libera è apparsa sull'host, ma la macchina virtuale non ha fretta di tornare da Swap alla RAM del server.
Prima di ESXi 6.0, l'unico modo affidabile e rapido per far uscire una VM da Swap era riavviare (per essere più precisi, spegnere/accendere il contenitore). A partire da ESXi 6.0, sebbene non del tutto ufficiale, è apparso un modo funzionante e affidabile per rimuovere una VM da Swap. In una delle conferenze ho avuto modo di parlare con uno degli ingegneri VMware incaricati di CPU Scheduler. Ha confermato che il metodo è abbastanza funzionante e sicuro. Nella nostra esperienza, non ci sono stati problemi neanche con esso.
I comandi effettivi per rimuovere la VM dallo Swap Duncan Epping. Non ripeterò una descrizione dettagliata, fornirò solo un esempio del suo utilizzo. Come puoi vedere nello screenshot, qualche tempo dopo l'esecuzione dei comandi specificati, Swap scompare dalla VM.
Suggerimenti per la gestione della memoria ESXi
Infine, ecco alcuni suggerimenti che ti aiuteranno a evitare problemi con le prestazioni della VM a causa della RAM:
- Evita l'oversubscription della memoria nei cluster produttivi. È auspicabile avere sempre circa il 20-30% di memoria libera nel cluster in modo che DRS (e l'amministratore) abbiano spazio di manovra e le VM non vadano in Swap durante la migrazione. Inoltre, non dimenticare il margine per la tolleranza ai guasti. È spiacevole quando, quando un server si guasta e la VM viene riavviata utilizzando HA, anche alcune macchine entrano in Swap.
- In infrastrutture altamente consolidate, cerca di NON creare VM con più della metà della memoria dell'host. Anche questo aiuterà DRS a distribuire le macchine virtuali sui server del cluster senza problemi. Questa regola, ovviamente, non è universale :).
- Controlla l'allarme di utilizzo della memoria dell'host.
- Non dimenticare di installare VMware Tools sulla VM e non disattivare Ballooning.
- Prendi in considerazione l'abilitazione del TPS tra macchine virtuali e la disabilitazione delle pagine di grandi dimensioni negli ambienti VDI e di test.
- Se la macchina virtuale riscontra problemi di prestazioni, verifica se sta utilizzando la memoria da un nodo NUMA remoto.
- Fai uscire la tua VM da Swap il più velocemente possibile! Tra l'altro se la VM è in Swap, per ovvie ragioni, il sistema di storage ne risente.
Questo è tutto per me sulla RAM. Di seguito è riportato un articolo correlato per coloro che vogliono approfondire i dettagli. Il prossimo articolo sarà dedicato a storadzh.
Link utili
Fonte: habr.com