{"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\/it\/blog\/administrirovanie\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","title":{"rendered":"Analisi delle prestazioni delle VM in VMware vSphere. Parte 2: Memoria","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Analisi
\n
\nParte 1. Sul CPU<\/a><\/noindex><\/p>\n

In questo articolo parleremo dei contatori delle prestazioni della memoria RAM in vSphere.
\nSembra che con la memoria tutto sia pi\u00f9 chiaro rispetto al processore: se ci sono problemi di prestazioni sulla VM, \u00e8 difficile non notarli. Tuttavia, affrontarli \u00e8 molto pi\u00f9 complicato. Ma andiamo con ordine. <\/a><\/noindex><\/p>\n

Un po' di teoria<\/h3>\n

\nLa memoria RAM delle macchine virtuali proviene dalla memoria del server su cui operano le VM. Questo \u00e8 abbastanza ovvio:). Se la memoria RAM del server non \u00e8 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. <\/p>\n

Quali tecniche applicare, ESXi lo decide in base al carico della memoria RAM:<\/p>\n

Stato della memoria<\/b><\/p>\n

Limite<\/b><\/p>\n

Azioni<\/b><\/p>\n

Alto<\/p>\n

400% di minFree<\/p>\n

Dopo aver raggiunto il limite superiore, le grandi pagine di memoria vengono suddivise in piccole (TPS funziona in modalit\u00e0 standard).<\/p>\n

Pulisci<\/p>\n

100% di minFree<\/p>\n

Le grandi pagine di memoria vengono suddivise in piccole, TPS funziona forzatamente.<\/p>\n

Morbido<\/p>\n

64% di minFree<\/p>\n

TPS + Balloon<\/p>\n

Duro<\/p>\n

32% di minFree<\/p>\n

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

Basso<\/p>\n

16% di minFree<\/p>\n

Compresso + Scambiare + Bloccare<\/p>\n

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

minFree \u00e8 la memoria RAM necessaria per il funzionamento dell'iperparavento. <\/p>\n

Fino a ESXi 4.1 incluso, minFree era impostato di default a un valore fisso \u2014 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\u00e0 della memoria nei server, minFree \u00e8 stata calcolata in base alla memoria del host anzich\u00e9 come valore percentuale fisso. <\/p>\n

Il valore di minFree (di default) \u00e8 calcolato nel seguente modo:<\/p>\n

Percentuale di memoria riservata per minFree<\/b><\/p>\n

Intervallo di memoria<\/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 rimanente<\/p>\n

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

Ad esempio, per un server con 128 GB di RAM, il valore di MinFree sar\u00e0:
\nMinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
\nIl valore effettivo pu\u00f2 variare di qualche centinaio di MB, a seconda del server e della memoria RAM.<\/p>\n

Percentuale di memoria riservata per minFree<\/b><\/p>\n

Intervallo di memoria<\/b><\/p>\n

Valore per 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 rimanente (100 GB)<\/p>\n

1024 MB<\/p>\n

\nIn genere, solo lo stato High \u00e8 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.<\/p>\n

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\u00f2 pi\u00f9 nel dettaglio. <\/p>\n

Trasparent Page Sharing (TPS).<\/b> Il TPS \u00e8, in parole semplici, la deduplicazione delle pagine di memoria RAM delle macchine virtuali su un server.<\/p>\n

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\u00f2 ottenere una certa sovrascrittura della memoria praticamente senza ridurre le prestazioni.<\/p>\n

\"Analisi
\nFonte<\/a><\/noindex><\/p>\n

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\u00e0 di trovare pagine identiche di tali dimensioni non \u00e8 alta.<\/p>\n

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).<\/p>\n

Se desideri che TPS inizi a funzionare senza attendere il riempimento della memoria del host, in Advanced Options di ESXi \u00e8 necessario impostare il valore \u201cMem.AllocGuestLargePage\u201d<\/i> a 0 (di default 1). In questo modo, l'allocazione di grandi pagine di memoria per le macchine virtuali sar\u00e0 disattivata.<\/p>\n

Dal dicembre 2014, in tutte le versioni di ESXi, TPS tra VM \u00e8 disattivato per impostazione predefinita, poich\u00e9 \u00e8 stata trovata una vulnerabilit\u00e0 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\u00e0 TPS.<\/p>\n

La politica TPS \u00e8 controllata tramite l'opzione avanzata \u201cMem.ShareForceSalting\u201d<\/i> su ESXi:
\n0 - Inter-VM TPS. TPS lavora per le pagine di diverse VM;
\n1 - TPS per VM con lo stesso valore \u201csched.mem.pshare.salt\u201d in VMX;
\n2 (di default) - Intra-VM TPS. TPS lavora per le pagine interne della VM.<\/p>\n

\u00c8 decisamente sensato disattivare le grandi pagine e attivare Inter-VM TPS su ambienti di test. Pu\u00f2 essere utilizzato anche in ambienti con un gran numero di VM omogenee. Ad esempio, negli ambienti con VDI, il risparmio di memoria fisica pu\u00f2 raggiungere decine di percento. <\/p>\n

Memory Ballooning.<\/b> Il Ballooning non \u00e8 pi\u00f9 una tecnica cos\u00ec innocua e trasparente per il sistema operativo della VM come il TPS. Ma con un uso appropriato, si pu\u00f2 convivere e persino lavorare con il Ballooning.<\/p>\n

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\u00e9 a livello di OS la memoria \u00e8 occupata dal Balloon Driver. Di default, il Balloon Driver pu\u00f2 sottrarre fino al 65% della memoria della VM.<\/p>\n

Se sulla VM non sono installati VMware Tools o se il Ballooning \u00e8 disattivato (non consiglio questa opzione, ma esiste KB<\/a><\/noindex>:), l'hypervisor passa subito a tecniche pi\u00f9 drastiche di sottrazione della memoria. Morale: assicurati che i VMware Tools siano installati sulla VM.<\/p>\n

\"Analisi
\nIl funzionamento del Balloon Driver pu\u00f2 essere verificato dal sistema operativo tramite VMware Tools.<\/i>.<\/p>\n

Memory Compression.<\/b> 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\u00ec 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\u00e9 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 \u00e8 molto efficace nella pratica.<\/p>\n

Memory Swapping.<\/b> 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 \u00e8 molto poca (stato di Low), il hypervisor smette anche di allocare pagine di memoria alle VM, il che pu\u00f2 causare problemi nei sistemi operativi guest delle VM.<\/p>\n

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: \u00e8 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' \u00e8 di diversi ordini di grandezza pi\u00f9 lenta rispetto a quella reale, anche se .vswp \u00e8 memorizzato su uno storage veloce.<\/p>\n

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\u00f2 essere spenta correttamente dal sistema operativo. Se avrete pazienza \ud83d\ude09<\/p>\n

Se le VM sono andate in Swap \u2014 si tratta di una situazione anomala che sarebbe meglio evitare il pi\u00f9 possibile.<\/p>\n

Principali contatori delle prestazioni della memoria della macchina virtuale<\/h3>\n

\nEccoci arrivati al punto principale. Per monitorare lo stato della memoria nella VM, ci sono i seguenti contatori:<\/p>\n

Active<\/b> \u2014 mostra la quantit\u00e0 di memoria RAM (KB) a cui la VM ha avuto accesso nel periodo di misurazione precedente.<\/p>\n

Utilizzo<\/b> \u2014 \u00e8 lo stesso di Attivo, ma in percentuale dalla memoria RAM configurata per la VM. Si calcola con la seguente formula: attivo \u00f7 dimensione della memoria configurata della macchina virtuale.
\nUn 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. \u00c8 pi\u00f9 un motivo per esaminare cosa sta succedendo nel sistema operativo.
\nC'\u00e8 un allarme standard per l'Utilizzo della Memoria per la VM:<\/p>\n

\"Analisi
\n
\nCondiviso<\/b> \u2014 quantit\u00e0 di memoria RAM della VM, deduplicata tramite TPS (all'interno della VM o tra VM).<\/p>\n

Concessa<\/b> \u2014 quantit\u00e0 di memoria fisica dell'host (KB) che \u00e8 stata assegnata alla VM. Include la Condivisa.<\/p>\n

Consumato<\/b> (Concessa - Condivisa) \u2014 quantit\u00e0 di memoria fisica (KB) che la VM consuma dall'host. Non include la Condivisa.<\/p>\n

Se una parte della memoria della VM \u00e8 assegnata non dalla memoria fisica dell'host, ma da un file di swap, oppure la memoria \u00e8 stata sottratta alla VM tramite Balloon Driver, questa quantit\u00e0 non \u00e8 inclusa nella Concessa e nel Consumato.
\nAlti 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\u00ec.<\/p>\n

Zero<\/b> \u2014 la quantit\u00e0 di memoria RAM della VM (KB) che contiene zeri. Questa memoria \u00e8 considerata libera dall'iper-vip e pu\u00f2 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\u00f9.<\/p>\n

Reserved Overhead<\/b> \u2014 la quantit\u00e0 di memoria RAM della VM (KB) riservata dall'iper-vip per il funzionamento della VM. \u00c8 un volume ridotto, ma deve necessariamente essere disponibile sull'host, altrimenti la VM non si avvier\u00e0.<\/p>\n

Balloon<\/b> \u2014 la quantit\u00e0 di memoria RAM (KB) sottratta alla VM tramite il Balloon Driver.<\/p>\n

Compressed<\/b> \u2014 la quantit\u00e0 di memoria RAM (KB) che \u00e8 stata ridotta.<\/p>\n

Swapped<\/b> \u2014 la quantit\u00e0 di memoria RAM (KB) che, in mancanza di memoria fisica sul server, \u00e8 stata spostata su disco.
\nI contatori di Balloon e delle altre tecniche di recupero della memoria sono pari a zero.<\/p>\n

Ecco come appare il grafico con i contatori della memoria di una VM funzionante con 150 GB di RAM.<\/p>\n

\"Analisi
\n
\nNel grafico sottostante, la VM presenta evidenti problemi. Si pu\u00f2 osservare che per questa VM sono state utilizzate tutte le tecniche descritte per la gestione della memoria. Il Balloon per questa VM \u00e8 notevolmente pi\u00f9 grande rispetto al Consumed. Di fatto, la VM \u00e8 pi\u00f9 morta che viva. <\/p>\n

\"Analisi
\n<\/p>\n

ESXTOP<\/h3>\n

\nCome per la CPU, se vogliamo valutare rapidamente la situazione sull'host, cos\u00ec come la sua dinamica con intervalli di 2 secondi, \u00e8 utile utilizzare ESXTOP.<\/p>\n

Lo schermo di ESXTOP per la memoria si attiva premendo il tasto \u00abm\u00bb e appare come segue (campi selezionati: B, D, H, J, K, L, O):<\/p>\n

\"Analisi
\n
\nI seguenti parametri saranno interessanti per noi: <\/p>\n

Mem overcommit avg<\/b> \u2014 valore medio del sovrascritto di memoria sull'host negli ultimi 1, 5 e 15 minuti. Se \u00e8 superiore a zero, \u00e8 un motivo per controllare cosa sta succedendo, ma non sempre \u00e8 indicativo di problemi.<\/p>\n

Nelle righe PMEM\/MB<\/b> e VMKMEM\/MB<\/b> \u2014 informazioni sulla memoria fisica del server e sulla memoria disponibile per il VMkernel. Qui \u00e8 interessante vedere il valore di minfree (in MB) e lo stato della memoria dell'host (nel nostro caso, alto).<\/p>\n

Nella riga NUMA\/MB<\/b> \u00e8 possibile vedere la distribuzione della memoria RAM tra i nodi NUMA (socket). In questo esempio, la distribuzione \u00e8 irregolare, il che non \u00e8 proprio ideale.<\/p>\n

Di seguito ci sono le statistiche generali del server relative alle tecniche di recupero della memoria:<\/p>\n

PSHARE\/MB<\/b> \u2014 queste sono le statistiche TPS;<\/p>\n

SWAP\/MB<\/b> \u2014 statistiche sull'uso dello Swap;<\/p>\n

ZIP\/MB<\/b> \u2014 statistiche sulla compressione delle pagine di memoria;<\/p>\n

MEMCTL\/MB<\/b> \u2014 statistiche sull'uso del Balloon Driver.<\/p>\n

Per singole VM, possiamo essere interessati alle seguenti informazioni. Ho nascosto i nomi delle VM per non confondere il pubblico:). Se la metrica ESXTOP \u00e8 analoga al contatore in vSphere, riporto il contatore corrispondente. <\/p>\n

MEMSZ<\/b> \u2014 quantit\u00e0 di memoria configurata sulla VM (MB).
\nMEMSZ = GRANT + MCTLSZ + SWCUR + untouched.<\/p>\n

GRANT<\/b> \u2014 Granted in MB.<\/p>\n

TCHD<\/b> \u2014 Active in MB.<\/p>\n

MCTL?<\/b> \u2014 se \u00e8 stato installato il Balloon Driver sulla VM.<\/p>\n

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

MCTLGT<\/b> \u2014 quantit\u00e0 di memoria RAM (MB) che ESXi desidera prelevare dalla VM tramite il Balloon Driver (Memctl Target).<\/p>\n

MCTLMAX<\/b> \u2014 quantit\u00e0 massima di memoria RAM (MB) che ESXi pu\u00f2 prelevare dalla VM tramite il Balloon Driver.<\/p>\n

SWCUR<\/b> \u2014 quantit\u00e0 attuale di memoria RAM (MB) fornita alla VM dal file di Swap. <\/p>\n

SWGT<\/b> \u2014 quantit\u00e0 di memoria RAM (MB) che ESXi desidera fornire alla VM dal file di Swap (Swap Target).<\/p>\n

Anche tramite ESXTOP \u00e8 possibile visualizzare informazioni pi\u00f9 dettagliate sulla topologia NUMA delle VM. Per fare ci\u00f2, \u00e8 necessario selezionare i campi D,G:<\/p>\n

\"Analisi
\n
\nNHN<\/b> \u2013 nodi NUMA su cui \u00e8 posizionata la VM. Qui si possono subito notare le VM wide che non rientrano in un singolo nodo NUMA.<\/p>\n

NRMEM<\/b> \u2013 quanti megabyte di memoria la VM utilizza da un nodo NUMA remoto.<\/p>\n

NLMEM<\/b> \u2013 quanti megabyte di memoria la VM utilizza da un nodo NUMA locale.<\/p>\n

N%L<\/b> \u2013 percentuale di memoria della VM sul nodo NUMA locale (se inferiore all'80% \u2014 potrebbero sorgere problemi di prestazioni).<\/p>\n

Memoria sull'ipervisore<\/h3>\n

\nSe i contatori CPU sull'ipervisore di solito non presentano particolare interesse, la situazione \u00e8 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. \u00c8 importante monitorare gli allarmi sull'Host Memory Usage e prevenire che la VM entri nello Swap.<\/p>\n

\"Analisi
\n
\n\"Analisi
\n<\/p>\n

Unswa<\/h3>\n

\nSe 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 \u00e8 disponibile sull'host, mentre il ritorno dalla Swap alla memoria RAM del server non avviene altrettanto rapidamente per la macchina virtuale.
\nFino alla versione ESXi 6.0, l'unico modo sicuro e veloce per uscire una VM dallo Swap era il riavvio (pi\u00f9 precisamente, lo spegnimento e accensione del contenitore). A partire da ESXi 6.0, \u00e8 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\u00e0 di discutere con uno degli ingegneri di VMware responsabile del CPU Scheduler. Ha confermato che il metodo \u00e8 effettivamente funzionante e sicuro. Nella nostra esperienza, non abbiamo riscontrato problemi con esso.<\/p>\n

Comandi per rimuovere una VM dallo Swap descritto<\/a><\/noindex> Duncan Epping. Non ripeter\u00f2 la descrizione dettagliata, ma fornir\u00f2 un esempio del suo utilizzo. Come si pu\u00f2 vedere nello screenshot, dopo un certo periodo dall'esecuzione del comando, la Swap sulla VM scompare.<\/p>\n

\"Analisi
\n<\/p>\n

Consigli per la gestione della memoria RAM su ESXi<\/h3>\n

\nInfine, ecco alcuni consigli per aiutarvi a evitare problemi di prestazioni delle VM legati alla memoria RAM:<\/p>\n