{"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. Riguardo alla CPU<\/a><\/noindex><\/p>\n

In questo articolo parleremo dei contatori delle prestazioni della memoria RAM in vSphere.
\nSembra che la questione della memoria sia pi\u00f9 chiara rispetto a quella del processore: se ci sono problemi di prestazioni nelle VM, \u00e8 difficile non notarli. Tuttavia, una volta che compaiono, affrontarli diventa molto pi\u00f9 complesso. 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 del server non \u00e8 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. <\/p>\n

Quali tecniche applicare ESXi decide in base al carico di memoria:<\/p>\n

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

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

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

High<\/p>\n

400% di minFree<\/p>\n

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

Cancella<\/p>\n

100% di minFree<\/p>\n

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

Soft<\/p>\n

64% di minFree<\/p>\n

TPS + Balloon<\/p>\n

Hard<\/p>\n

32% di minFree<\/p>\n

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

Basso<\/p>\n

16% di minFree<\/p>\n

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

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

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

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 \u00e8 stato calcolato in base alla quantit\u00e0 di memoria dell'host, anzich\u00e9 come valore fisso percentuale. <\/p>\n

Il valore di minFree (di default) viene calcolato come segue:<\/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 residua<\/p>\n

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

Ad esempio, per un server con 128 GB di RAM, il valore di MinFree sar\u00e0 il seguente:
\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 residua (100 GB)<\/p>\n

1024 MB<\/p>\n

\nDi solito, solo lo stato High pu\u00f2 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.<\/p>\n

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\u00f2 di loro in modo pi\u00f9 dettagliato. <\/p>\n

Condivisione di Pagine Trasparenti (TPS).<\/b> Il TPS \u00e8, in parole povere, la deduplicazione delle pagine di RAM delle macchine virtuali sul server.<\/p>\n

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\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 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\u00e0 di trovare pagine identiche di tale dimensione \u00e8 bassa.<\/p>\n

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

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 \u201cMem.AllocGuestLargePage\u201d<\/i> a 0 (valore predefinito 1). In questo modo, l'allocazione delle grandi pagine di memoria per le macchine virtuali sar\u00e0 disabilitata.<\/p>\n

Da dicembre 2014, in tutte le versioni di ESXi, il TPS tra VM \u00e8 disabilitato per impostazione predefinita, poich\u00e9 \u00e8 stata trovata una vulnerabilit\u00e0 che permette teoricamente di accedere alla RAM di un'altra VM. Maggiori dettagli qui. Non ho trovato informazioni sulla concreta implementazione della vulnerabilit\u00e0 TPS.<\/p>\n

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

\u00c8 sicuramente sensato disabilitare le pagine di grandi dimensioni e abilitare l'Inter-VM TPS sui banchi di prova. Questo pu\u00f2 anche essere utilizzato per banchi con un gran numero di VMs simili. Ad esempio, sui banchi 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 delle VMs, come lo \u00e8 il TPS. Ma se usato correttamente, si pu\u00f2 convivere e persino lavorare con il Ballooning.<\/p>\n

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

Se sulla VM non sono installati VMware Tools o se il Ballooning \u00e8 disabilitato (non lo consiglio, ma esiste KB<\/a><\/noindex>:), l'ipervisore passa subito a tecniche pi\u00f9 aggressive per il recupero della memoria. Conclusione: assicurati che i VMware Tools siano installati sulla VM.<\/p>\n

\"Analisi
\n\u00c8 possibile controllare il funzionamento del Balloon Driver dal SO tramite i VMware Tools.<\/i>.<\/p>\n

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

Memory Swapping.<\/b> 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\u00f2 causare problemi nei sistemi operativi guest delle VMs.<\/p>\n

Ecco come funziona lo Swapping. Quando viene avviata la macchina virtuale, viene creato un file con estensione .vswp. La sua dimensione \u00e8 pari alla memoria volatile non riservata della VM: \u00e8 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\u00e9 con la memoria fisica del server. Naturalmente, tale \"memoria\" \u00e8 molto pi\u00f9 lenta rispetto a quella reale, anche se il file .vswp si trova su uno storage veloce.<\/p>\n

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\u00f2 essere disattivata correttamente dal sistema operativo, se si ha pazienza \ud83d\ude09<\/p>\n

Se una VM \u00e8 finita nello Swap, si tratta di una situazione anomala che sarebbe meglio evitare.<\/p>\n

Le principali metriche delle prestazioni della memoria della macchina virtuale<\/h3>\n

\nE siamo arrivati al punto centrale. Per monitorare lo stato della memoria nella VM ci sono le seguenti metriche:<\/p>\n

Attivo<\/b> \u2014 mostra la quantit\u00e0 di memoria volatile (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 rispetto alla memoria volatile configurata della VM. Si calcola con la seguente formula: attivo \u00f7 dimensione della memoria configurata della macchina virtuale.
\nUn alto Utilizzo e Attivo, rispettivamente, non \u00e8 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, \u00e8 un motivo per verificare cosa sta succedendo nel sistema operativo.
\nC'\u00e8 un allarme standard per l'Utilizzo della Memoria per la VM:<\/p>\n

\"Analisi
\n
\nShared<\/b> \u2014 quantit\u00e0 di memoria volatile della VM, de-duplicata tramite TPS (all'interno della VM o tra VM).<\/p>\n

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

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

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 \u00e8 stata sottratta dalla VM tramite il Balloon Driver, questa quantit\u00e0 non viene conteggiata nei valori Concesso e Consumato.
\nValori 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\u00e0 di memoria configurata, e rimangono l\u00ec.<\/p>\n

Zero<\/b> \u2014 quantit\u00e0 di memoria RAM della VM (Kbyte) che contiene zeri. Questa memoria \u00e8 considerata libera dall'hypervisor e pu\u00f2 essere assegnata ad altre macchine virtuali. Dopo che il sistema operativo guest ha scritto qualcosa nella memoria azzerata, passa a Consumed e non pu\u00f2 essere restituita.<\/p>\n

Riserva di sovraccarico<\/b> \u2014 quantit\u00e0 di memoria RAM della VM (Kbyte) riservata dall'hypervisor per il funzionamento della VM. Questa \u00e8 una piccola quantit\u00e0, ma deve essere necessariamente disponibile sull'host, altrimenti la VM non si avvia.<\/p>\n

Balloon<\/b> \u2014 quantit\u00e0 di memoria RAM (Kbyte) prelevata dalla VM tramite Balloon Driver.<\/p>\n

Compresso<\/b> \u2014 quantit\u00e0 di memoria RAM (Kbyte) che \u00e8 stata compressa.<\/p>\n

Scambiata<\/b> \u2014 quantit\u00e0 di memoria RAM (Kbyte) che, in assenza di memoria fisica sul server, \u00e8 stata trasferita su disco.
\nBalloon e gli altri contatori delle tecniche di recupero della memoria sono pari a zero.<\/p>\n

Ecco come appare un grafico con i contatori di una VM che funziona normalmente con 150 GB di RAM.<\/p>\n

\"Analisi
\n
\nNel grafico sottostante, la VM presenta evidenti problemi. Sotto il grafico si pu\u00f2 vedere che per questa VM sono state utilizzate tutte le tecniche descritte per la gestione della memoria. Balloon per questa VM \u00e8 significativamente pi\u00f9 grande di Consumed. In realt\u00e0, 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 e la sua dinamica con intervalli fino a 2 secondi, vale la pena utilizzare ESXTOP.<\/p>\n

Lo schermo di ESXTOP per la memoria si attiva con il tasto \u00abm\u00bb e appare come segue (sono stati selezionati i campi 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 di overcommit della memoria sull'host negli ultimi 1, 5 e 15 minuti. Se \u00e8 superiore a zero, \u00e8 un motivo per esaminare cosa sta succedendo, ma non \u00e8 sempre un indicatore 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. Di interessante qui si pu\u00f2 vedere il valore minfree (in MByte), lo stato della memoria dell'host (nel nostro caso, alto).<\/p>\n

Nella riga NUMA\/MB<\/b> si pu\u00f2 vedere la distribuzione della memoria RAM sulle nodi NUMA (socket). In questo esempio la distribuzione \u00e8 irregolare, il che non \u00e8 molto positivo.<\/p>\n

Di seguito sono statistiche generali sul server per le tecniche di recupero della memoria:<\/p>\n

PSHARE\/MB<\/b> \u2014 \u00e8 la statistica TPS;<\/p>\n

SWAP\/MB<\/b> \u2014 statistica sull'utilizzo dello Swap;<\/p>\n

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

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

Per singole VM, potrebbe interessarci la seguente informazione. 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 volume di memoria configurato 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 sulla VM \u00e8 stato installato il Balloon Driver.<\/p>\n

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

MCTLGT<\/b> \u2014 volume di memoria RAM (MB) che ESXi desidera sottrarre alla VM tramite il Balloon Driver (Memctl Target).<\/p>\n

MCTLMAX<\/b> \u2014 volume massimo di memoria RAM (MB) che ESXi pu\u00f2 sottrarre alla VM tramite il Balloon Driver.<\/p>\n

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

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

Attraverso ESXTOP \u00e8 possibile visualizzare informazioni pi\u00f9 dettagliate sulla topologia NUMA della VM. Per farlo, \u00e8 necessario selezionare i campi D,G:<\/p>\n

\"Analisi
\n
\nNHN<\/b> \u2013 nodi NUMA su cui si trova la VM. Qui \u00e8 possibile notare subito wide vm che non si adattano a un singolo nodo NUMA.<\/p>\n

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

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

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

Memoria sull'ipervisor<\/h3>\n

\nSe i contatori CPU sull'ipervisor generalmente non suscitano particolare interesse, la situazione con la memoria \u00e8 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. \u00c8 necessario monitorare gli allarmi sull'Utilizzo della Memoria dell'Host e prevenire l'ingresso della VM nello Swap.<\/p>\n

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

Unswap<\/h3>\n

\nSe la VM \u00e8 finita nello Swap, le sue prestazioni diminuiscono notevolmente. I segni del Ballooning e della compressione svaniscono rapidamente dopo che la memoria RAM \u00e8 tornata disponibile sull'host, mentre la macchina virtuale non si affretta a tornare dalla Swap alla memoria RAM del server.
\nFino 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 \u00e8 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 \u00e8 sicuramente funzionante e sicuro. Nel nostro esperienza non abbiamo riscontrato problemi con esso.<\/p>\n

Comandi per estrarre la VM dallo Swap ha 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 po' di tempo dall'esecuzione del comando indicato, lo Swap sulla VM scompare.<\/p>\n

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

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

\nPer concludere, ecco alcuni consigli che possono aiutarti a evitare problemi di prestazioni delle VM a causa della memoria operativa:<\/p>\n