C'è molto di più di ESXi in questione qui,
- Ogni VM consumerà fino a 4 GB + "sovraccarico", che è documentato qui . Questo dipende dalle vCPU, + memoria allocata. Almeno ogni VM utilizzerà 4261,98 MB (4096 + 165,98)
- L'overhead della memoria di ESXi dipende dall'hardware. L'opzione più semplice è esaminare l' utilizzo della memoria di sistema nel client vSphere. Dalla memoria ricordo che è intorno al segno di 1,3 GB, ma come detto che dipende molto dall'hardware.
Spiegazione dell'allocazione e del sovraccarico di memoria
Si noti che l'hypervisor non alloca tutta la memoria in anticipo , dipende dall'utilizzo della VM. Tuttavia, vale la pena capire cosa accadrà se le macchine virtuali tentassero di allocare e utilizzare tutta la memoria loro assegnata.
Il massimo che l'host di VM + proverà a utilizzare sarà approssimativamente di 55 GB, il chilometraggio può variare
- 1.3 GB utilizzati da ESXi
- 4261,98 MB * 13 utilizzati dalle macchine virtuali
C'è un altro aspetto da tenere in considerazione e quello è la soglia di memoria. Per impostazione predefinita, VMware punta a liberare il 6% (soglia di memoria elevata). Pertanto, i 55 GB di memoria utilizzata devono essere ridotti a ~ 45 GB
Ciò significa che l'host avrà circa 10.500 MB di memoria necessari per essere recuperati da qualche parte nel caso in cui le VM utilizzino la memoria assegnata. Esistono tre cose che ESX fa per trovare altri 10,5 GB.
Metodi di recupero della memoria
- Condivisione trasparente delle pagine
- Memory Ballooning
- Scambio hypervisor
È necessario leggere e comprendere Comprensione della gestione delle risorse di memoria nel server VMware® ESX ™ .
A seconda di un gran numero di fattori, una combinazione di tutti e tre potrebbe / potrebbe accadere su un host troppo impegnato. È necessario testare il proprio impegno e monitorare queste metriche per comprendere l'impatto dell'eccessivo impegno.
Alcune regole approssimative che vale la pena conoscere (tutte nel documento sopra e altre fonti).
- La condivisione trasparente delle pagine non avviene per le macchine virtuali che utilizzano pagine da 2/4 MB. Dopo aver allocato 4096 MB per le macchine virtuali Windows, per impostazione predefinita utilizzeranno le pagine da 2/4 MB (in base a PAE). Solo sotto pressione della memoria VMware suddividerà le pagine grandi fino a 4 KB che possono essere condivise. TPS si affida all'utilizzo di cicli di CPU inattivi e alla scansione di pagine di memoria a una determinata velocità. Restituisce la memoria relativamente lentamente (pensa un'ora anziché minuti). Quindi una tempesta di avvio significa che TPS non ti aiuterà. Dai tre, questo ha il minor impatto sulle prestazioni. Altro dal documento,
Nella virtualizzazione della memoria assistita da hardware (ad esempio, Intel EPT Hardware Assist e AMD RVI Hardware Assist [6]), ESX eseguirà automaticamente il backup di pagine fisiche guest con pagine fisiche host di grandi dimensioni (2 MB di area di memoria contigua anziché 4KB per pagine normali) per migliori prestazioni grazie a meno mancati TLB. In tali sistemi, ESX non condividerà quelle pagine di grandi dimensioni perché: 1) la probabilità di trovare due pagine di grandi dimensioni con contenuti identici è bassa e 2) il sovraccarico di fare un confronto bit per bit per una pagina di 2 MB è molto più grande di per una pagina 4KB. Tuttavia, ESX genera ancora hash per le pagine 4KB all'interno di ogni pagina di grandi dimensioni. Poiché ESX non sostituirà le pagine di grandi dimensioni, durante lo scambio di host, la pagina grande verrà suddivisa in piccole pagine in modo che questi hash pre-generati possano essere utilizzati per condividere le piccole pagine prima che vengano scambiate. In breve, potremmo non osservare alcuna condivisione di pagina per i sistemi di virtualizzazione della memoria assistita dall'hardware fino a quando la memoria dell'host non viene sovraccaricata.
La mongolfiera inizia in seguito (le soglie sono configurabili, per impostazione predefinita è quando l'host ha meno del 6% di memoria libera (tra alta e software)). Assicurati di installare il driver e fai attenzione a Java e alle applicazioni gestite in generale. Il sistema operativo non ha idea di cosa farà il garbage collector e finirà per colpire le pagine che sono state scambiate su disco. Non è una pratica insolita per i server che eseguono applicazioni Java esclusivamente disabilitare lo scambio per garantire che ciò non accada. Dai un'occhiata a Pagina 17 di vSphere Memory Management, SPECjbb
Scambio di hypervisor , dai tre metodi è l'unico che garantisce che la "memoria" sia disponibile per l'hypervisor in un tempo prestabilito. Questo sarà utilizzato se 1 & 2 non dare abbastanza memoria per rimanere sotto la dura soglia (default di memoria libera 2%). Quando leggi le metriche delle prestazioni (fai le tue), ti rendi conto che questa è la peggiore delle tre. Cerca di evitarlo a tutti i costi poiché l'impatto sulle prestazioni sarà molto evidente su quasi tutte le applicazioni con una percentuale a doppia cifra
C'è un altro stato di cui tenere conto di basso (per impostazione predefinita 1%). Dal manuale questo può ridurre drasticamente le tue prestazioni,
In un raro caso in cui la memoria libera dell'host scende al di sotto della soglia bassa, l'hypervisor continua a recuperare memoria attraverso lo scambio e la compressione della memoria e blocca ulteriormente l'esecuzione di tutte le macchine virtuali che consumano più memoria rispetto alle allocazioni di memoria di destinazione.
Sommario
Il punto chiave da sottolineare è che è impossibile prevedere dai white paper come si comporterà l'ambiente.
- Quanto ti può dare TPS? (Dipende da quanto sono simili le VM con il loro sistema operativo, Service Pack e applicazioni in esecuzione)
- Con quale velocità le tue VM allocano la tua memoria? Più rapidamente lo fanno, più è probabile che si salti alla soglia successiva prima che lo schema di recupero della memoria meno efficace riesca a mantenerti nella soglia corrente.
- A seconda dell'applicazione, ogni schema di recupero della memoria avrà un impatto molto variabile.
Metti alla prova i tuoi scenari medi, sei al 95% in percentuale e infine il massimo per capire come verrà eseguito il tuo ambiente.
Modifica 1
Vale la pena aggiungere che con vSphere 4 (o 4.1 non è possibile richiamare), è ora possibile posizionare lo scambio hypervisor sul disco locale ma ancora vmotion la VM. Se si utilizza l'archiviazione condivisa, si consiglia vivamente di spostare il file di scambio dell'hypervisor in modo che si trovi sul disco locale per impostazione predefinita. Ciò garantisce che quando un host è sottoposto a una forte pressione della memoria, non ha un impatto su tutti gli altri host / VM vSphere sullo stesso storage condiviso.
Modifica 2
Sulla base dei commenti, ha fatto il fatto che ESX non alloca la memoria in grassetto in grassetto ...
Modifica 3
Spiegato un po 'di più sulle soglie di memoria.