Home > virtualization, vmware, vsphere > La gestione della memoria in VMware ESX 4.1 – parte 3

La gestione della memoria in VMware ESX 4.1 – parte 3

Nella prima e nella seconda parte di questi articoli, ho analizzato i concetti di base di gestione della memoria e le tecniche “consolidate” di memory reclamation utilizzate da ESX 4.1: il trasparent page sharing, il ballooning e lo swapping.

In questa terza ed ultima parte analizzerò la tecnica della compressione della memoria, nuova arrivata in ESX 4.1. Illustrerò poi  quando entrano in funzione i vari meccanismi e infine indicherò dei riferimenti per ulteriori approfondimenti.

La compressione della memoria

L’idea alla base della compressione della memoria è semplice: se le pagine da swappare possono essere compresse e messe in una cache nella memoria principale, il prossimo accesso alla pagina causerà soltanto una decompressione che può essere un ordine di grandezza più veloce di un accesso al disco. Con la compressione della memoria solo un ridotto numero di pagine non comprimibili ha bisogno di essere swappato se la cache di compressione non è piena, riducendo così il numero di caricamenti in memoria futuri. Così facendo è possibile che le performance delle applicazioni migliorino quando l’host è in ristrettezze di memoria.

In ESX4.1 la compressione della memoria avviene solo per le pagine che dovrebbero essere swappate: se la memoria non è overallocata il meccanismo di compressione della memoria non entra in funzione.

Come funziona

Come appena detto, la compressione della memoria entra in gioco solo quando ESX ha bisogno di recuperare delle pagine tramite swap. Assumiamo che ESX abbia individuato due pagine da 4KB di una vm da recuperare tramite swap. Con la compressione della memoria, ogni pagina candidata viene compressa e memorizzata usando 2 KB di spazio in una zona di memoria dedicata che ogni VM ha (detta compression cache). Dato che non ci sono I/O su disco, la compressione delle pagine è più veloce dello swap. Se il rapporto di compressione fosse minore del 50%, le pagine verrebbero swappate normalmente, in questo modo ogni compressione eseguita con successo recupera 2KB di physical memory.

Quando un accesso successivo nella VM guest memory genera un miss, viene per prima verificata la presenza nella compression cache: se la pagina viene trovata qui, viene decompressa e riportata nella guest memory, eliminandola dalla compression cache. Se non viene trovata nella compression cache, la richiesta va allo swap.

Riassumendo: il meccanismo di compressione della memoria entra in funzione solo quando l’hypervisor avrebbe bisogno di swappare. Basandosi sul fatto che la compressione e l’accesso in ram sono più veloci dell’accesso al disco, l’hypervisor prova a comprimere le pagine e salvarle in una zona dedicata. Se il rapporto di compressione delle pagine supera il 50%, vengono salvate nella zona dedicata, altrimenti vengono swappate.

La compression cache

Lo spazio per la  compression cache (la zona di memoria dedicata che ogni VM ha per il meccanismo di compressione della memoria) viene considerata nell’uso della guest memory delle VM: ESX non alloca ulteriore host physical memory per memorizzare le pagine compresse.

La compression cache è trasparente per il sistema operativo guest, la sua dimensione parte a zero e cresce via via che la memoria della VM viene swappata.

Quando la compression cache è piena, una pagina compressa (scelta tramite un politica basata sull’age-ing) viene decompressa e swappata per fare posto alla nuova pagina.

Se le pagine appartenenti alla compression cache devono essere swappate per colpa di una pesante overallocazione, la dimensione della compression cache viene ridotta  e le pagine “di troppo” vengono decompresse e swappate.

ESX setta in modo conservativo la dimensione massima della ompression cache al 10% della dimensione configurata della VM. La dimensione massima della compression cache è importante per mantenere delle buone performance della VM: se troppo piccola ci sarebbero molte sostituzioni di pagine compresse con conseguente decompressione e swap, se troppo grande può sprecare memoria della VM e creare inutilmente pressione nel caso le pagine compresse non siano più toccate in seguito.

Quando partono i meccanismi di memory reclamation?

Finora ho illustrato le tecniche di memory reclamation utilizzate da ESX 4.1 indicando l’ordine in cui vengono applicate, ossia: transparent page sharing, ballooning, compressione della memoria e swapping. Ho inoltre detto come ESX le usa via via che la memoria libera diminuisce. Ma quando effettivamente ESX decide di utilizzare le varie tecniche?

ESX definisce quattro stati per l’host memory libera: high, soft, hard e low corrispondenti a quattro soglie di memoria libera: 6%, 4%, 2%, 1%.

Di default ESX abilita sempre il trasparent page sharing, in quanto opera in modo opportunistico liberando memoria con poco overhead.

La decisione di abilitare il ballooning o lo swapping (che a sua volta attiva la compressione della memoria) dipende invece in larga parte dallo stato attuale della host memory libera.

In stato high, l’uso aggregato della guest memory delle VM è minore della dimensione della host memory: in questa situazione l’hypervisor non usa ballooning o swapping, indipendentemente dal fatto che la host memory sia overallocata. (A meno di memory limit impostati sulle VM).

In stato soft, l’hypervisor comincia ad utilizzare il ballooning: in particolare il ballooning inizia prima che sia raggiunta la soglia soft per far sì che il driver di ballooning abbia il tempo di allocare e bloccare la memoria e l’hypervisor possa quindi recuperarla anche prima di raggiungere la soglia soft.

Se nemmemo il ballooning è sufficiente e la memoria libera va in stato hard, l’hypervisor comincia ad usare lo swapping e la compressione della memoria. Tramite questi meccanismi l’hypervisor dovrebbe riuscire a recuperare rapidamente la memoria e riportarsi in stato soft.

Nei rari casi in cui si arriva allo stato low, l’hypervisor continua ad usare lo swapping e la compressione della memoria ma in più blocca l’esecuzione di tutte le VM che consumano più memoria del loro target di allocazione.

In alcune situazione la memoria viene recuperata indipendentemente dallo stato, ad esempio nel caso di VM che stanno superando il memory limit imposto. In questi casi viene utilizzato il ballooning e, se necessario, swapping e compressione fino a ridurre l’uso entro il limite imposto.

 

Con questo si conclude questa terza e ultima parte della miniserie dedicata alle tecniche di gestione della memoria di ESX 4.1.

Per chi volesse approfondire ulteriormente l’argomento, ecco alcuni link utili:

[tweetmeme only_single=”false”]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: