VMware ESXi: Troubleshooting Performance — CPU Ready, Memory Balloon, Storage Latency (2026)

Quando un cluster VMware in produzione inizia a rallentare, la frustrazione può salire rapidamente. Le VM diventano lente, gli utenti segnalano tempi di risposta inaccettabili, ma i sistemi di monitoraggio sembrano non rilevare alcun allarme critico. È uno scenario che ho vissuto personalmente: un’organizzazione con diverse centinaia di VM su host ESXi, dove improvvisamente tutto sembrava andare a rilento. Dopo un’analisi preliminare, ho scoperto che le performance erano compromesse da un valore di CPU Ready al 23% sull’host principale, causato da quattro VM ad alta intensità di memoria concentrate sullo stesso nodo. Un vMotion manuale su altri host ha riportato il CPU Ready al 2% e le performance sono triplicate senza alcun intervento hardware.

Questo esempio sottolinea un punto fondamentale: la diagnosi accurata è cruciale. Spesso, non si tratta di un problema di hardware sottodimensionato, ma di configurazioni subottimali o di una distribuzione inefficace del carico di lavoro. Comprendere i principali colli di bottiglia e saper interpretare le metriche di performance è la chiave per mantenere un ambiente virtuale efficiente e reattivo. Questo articolo ti guiderà attraverso le tecniche e gli strumenti essenziali per diagnosticare e risolvere i problemi di performance più comuni su VMware ESXi, focalizzandosi su CPU Ready, Memory Ballooning e Storage Latency.

Prerequisiti / Ambiente di test

Per seguire questa guida, avrai bisogno di un ambiente VMware vSphere (ESXi e vCenter Server) in esecuzione. Idealmente, un ambiente di test o uno di sviluppo dove puoi sperimentare senza impattare la produzione. È consigliabile avere accesso SSH agli host ESXi per utilizzare strumenti come esxtop e permessi adeguati su vCenter per visualizzare i Performance Charts. Tutti i comandi e le procedure descritte sono testati su VMware vSphere 7.x e 8.x.

I 4 colli di bottiglia ESXi: CPU, memoria, storage, rete

Un ambiente virtualizzato è un sistema complesso dove le risorse hardware vengono astratte e condivise tra più macchine virtuali. I problemi di performance emergono quando la domanda di una risorsa supera l’offerta disponibile o la capacità di gestione dell’hypervisor. I quattro principali colli di bottiglia sono:

1. CPU: Quando le VM richiedono più cicli di CPU di quanti l’host possa fornire o schedulare efficacemente.
2. Memoria: Quando la RAM fisica dell’host è insufficiente per le VM, costringendo l’hypervisor a utilizzare tecniche di gestione della memoria che degradano le performance.
3. Storage: Quando il sottosistema di archiviazione non è in grado di soddisfare le richieste di I/O delle VM in modo tempestivo, causando latenza.
4. Rete: Quando la larghezza di banda o la latenza della rete fisica o virtuale limitano la comunicazione delle VM.

Identificare quale di questi quattro elementi sia il fattore limitante è il primo passo per risolvere qualsiasi problema di performance.

CPU Ready: cos’è e quando preoccuparsi (>5%)

Il parametro CPU Ready (RDY) è forse la metrica più critica per valutare la performance della CPU di una VM. Misura la percentuale di tempo in cui una macchina virtuale è pronta per eseguire istruzioni CPU, ma non può farlo perché l’host ESXi non ha risorse fisiche di CPU disponibili per schedularla. In altre parole, la VM sta aspettando il suo turno.

Un valore di CPU Ready elevato indica che l’host è sovraccarico di CPU. Generalmente, un valore superiore al 5% per una singola VM è un campanello d’allarme, mentre valori costantemente superiori al 10-15% sono critici e indicano una grave contesa di risorse CPU. Ad esempio, in ambienti enterprise, ho riscontrato che un CPU Ready superiore al 10% spesso coincide con segnalazioni di rallentamenti significativi da parte degli utenti.

Le cause comuni di CPU Ready elevato includono:

• Over-provisioning di vCPU: Assegnare troppe vCPU a una VM può essere controproducente. L’hypervisor deve attendere che un numero sufficiente di core fisici sia disponibile contemporaneamente per schedulare la VM (co-scheduling), aumentando il tempo di attesa.
• Eccessivo carico sull’host: Troppe VM ad alta intensità di CPU sullo stesso host.
• Impostazioni di risorsa non ottimali: Limiti o reservation di CPU mal configurati.

Per ridurre il CPU Ready, valuta di ridurre il numero di vCPU assegnate alle VM che non ne hanno strettamente bisogno, bilanciare il carico di lavoro spostando le VM su host meno utilizzati (vMotion) o aggiungere risorse CPU all’host.

Memory Balloon e Swap: sintomi e contromisure

La gestione della memoria in VMware è un equilibrio delicato. Quando la memoria fisica disponibile sull’host ESXi inizia a scarseggiare, l’hypervisor adotta diverse tecniche per recuperarla e assegnarla alle VM che ne hanno bisogno. Le due più significative, e spesso indice di problemi, sono Memory Ballooning e Swap.

• Memory Ballooning: Il driver vmmemctl (il cosiddetto ‘balloon driver’) viene installato all’interno del sistema operativo guest. Quando l’host ha bisogno di memoria, il driver ‘prende in prestito’ memoria dal guest, facendogli credere di averne meno. Questo costringe il sistema operativo guest a rilasciare pagine di memoria non utilizzate o a fare swap interno, senza che l’hypervisor debba ricorrere a tecniche più drastiche. È un meccanismo efficiente, ma un ballooning eccessivo indica che l’host è sotto pressione di memoria.
• Swap: Se il ballooning non è sufficiente o non è possibile (ad esempio, il driver non è installato o il guest è troppo carico), l’host ESXi inizia a fare swapping della memoria delle VM su disco (file .vswp). Questa è la forma più lenta e dannosa di gestione della memoria, poiché l’accesso al disco è ordini di grandezza più lento dell’accesso alla RAM. Un’attività di swap (mem.swapin e mem.swapout in esxtop) è un segnale di allarme rosso che indica una grave carenza di memoria fisica.

Contromisure:

1. Ottimizzare la RAM delle VM: Assegna solo la quantità di RAM necessaria. Un eccessivo over-provisioning di RAM inattiva è uno spreco.
2. Aumentare la RAM fisica: Se persiste, l’unica soluzione è aggiungere RAM agli host.
3. Bilanciare il carico di memoria: Spostare VM con alte richieste di memoria su host con più RAM disponibile.

Storage latency: DAVG, KAVG, GAVG — cosa significano

La latenza di storage è spesso la causa più difficile da diagnosticare e risolvere, ma ha un impatto enorme sulle performance delle VM. VMware fornisce metriche dettagliate per aiutare a isolare dove si verifica la latenza nel percorso I/O. Le tre più importanti sono:

• DAVG (Device Average Latency): Il tempo medio che l’I/O impiega per essere completato dal dispositivo di storage fisico (es. array SAN/NAS, SSD locale). Valori costantemente superiori a 10-20ms indicano un problema a livello dell’array di storage o della connettività fisica.
• KAVG (Kernel Average Latency): Il tempo medio che l’I/O impiega nel kernel ESXi. Valori elevati qui possono indicare problemi con il driver dell’HBA, la coda di I/O dell’host o un sovraccarico dell’HBA stesso.
• GAVG (Guest Average Latency): Il tempo medio che l’I/O impiega dal punto di vista della VM. Questo è il valore totale che la VM percepisce. GAVG = DAVG + KAVG + QAVG (QAVG è il tempo di attesa nella coda del driver della VM).

Diagnosi e Contromisure:

1. Isolare il problema: Se DAVG è alto, il problema è nell’array o nella rete di storage. Se KAVG è alto, è nell’host ESXi. Se GAVG è alto ma DAVG e KAVG sono bassi, il problema potrebbe essere all’interno della VM (es. driver non aggiornati, file system frammentato).
2. Verificare la connettività: Assicurati che switch Fibre Channel o iSCSI siano configurati correttamente e non siano sovraccarichi. Controlla la qualità dei cavi.
3. Ottimizzare l’array: Rivedi le configurazioni RAID, i tiering, e la capacità IOPS dello storage.
4. Driver e firmware: Assicurati che i driver e il firmware degli HBA (Host Bus Adapter) siano aggiornati e certificati per la tua versione di ESXi. Ho visto casi in cui driver obsoleti causavano latenze inspiegabili.

esxtop: i contatori essenziali per ogni categoria

esxtop è lo strumento a riga di comando per eccellenza per il monitoring real-time delle performance su ESXi. È incredibilmente potente ma richiede pratica per essere padroneggiato. Per avviarlo, connettiti via SSH all’host ESXi e digita esxtop.

esxtop

Una volta avviato, puoi navigare tra le diverse schermate premendo i tasti:

• c per CPU: Focus sulle metriche CPU. Cerca %RDY (CPU Ready), %USED (CPU utilizzata), %SYS (CPU utilizzata dal kernel ESXi).
• m per Memoria: Focus sulle metriche di memoria. Cerca MEMSZ (dimensione RAM VM), ACTV (memoria attiva), SWCUR (memoria scambiata su disco), MCTLSZ (memoria ballooned).
• d per Storage Disk: Focus sulle metriche I/O dei dischi. Cerca DAVG, KAVG, GAVG (latenze), CMDS/s (comandi I/O al secondo), READS/s, WRITES/s.
• n per Rete: Focus sulle metriche di rete. Cerca PKTTX/s, PKTRX/s (pacchetti trasmessi/ricevuti), DRPTX/s, DRPRX/s (pacchetti scartati).

Per analisi storiche o per integrare con altri sistemi, puoi usare esxtop in modalità batch:

esxtop -b -d 5 -n 20 > esxtop_output.csv

Questo comando raccoglie dati ogni 5 secondi per 20 iterazioni e li salva in un file CSV, facilmente analizzabile con Excel o altri strumenti.

Per identificare rapidamente le VM con CPU Ready elevato tramite PowerCLI (utile per ambienti con molti host e VM):

Get-VM | Get-Stat -Stat cpu.ready.summation -Realtime | Where-Object {$_.Value -gt 5000} | Select-Object Entity, Value

Questo script PowerCLI cerca VM con un valore di CPU Ready superiore a 5000ms (che corrisponde a 5% in un intervallo di 20 secondi) in tempo reale, fornendo un output immediato delle VM problematiche.

vCenter Performance Charts: lettura e interpretazione

I Performance Charts di vCenter Server offrono una vista grafica e storica delle metriche di performance, indispensabile per identificare trend, picchi e correlazioni. Puoi accedere ai grafici selezionando un host, un cluster o una VM e navigando nella scheda ‘Monitor’ -> ‘Performance’ -> ‘Advanced’.

Punti chiave da monitorare:

• CPU: Grafici di CPU Usage, CPU Ready, CPU Co-stop. Un picco improvviso in CPU Ready senza un aumento proporzionale in CPU Usage può indicare un problema di co-scheduling.
• Memoria: Grafici di Consumed Memory, Active Memory, Ballooned Memory, Swapped Memory. Se la linea di Swapped Memory inizia a salire, hai un problema di memoria critico.
• Storage: Grafici di Disk Latency (Average, Read, Write), Disk Usage (Read/Write Rate). Correlare la latenza con il throughput di I/O può aiutare a capire se il problema è di capacità o di congestione.
• Rete: Grafici di Network Usage (Transmit/Receive Rate), Packet Drop Rate. I packet drop sono un chiaro segno di congestione o problemi di configurazione di rete.

L’abilità sta nel correlare queste metriche. Ad esempio, un aumento di CPU Ready che coincide con un picco di Storage Latency potrebbe suggerire che il collo di bottiglia è lo storage, che non riesce a fornire dati abbastanza velocemente alla CPU.

Quando aggiungere hardware vs ottimizzare config

La decisione di acquistare nuovo hardware (CPU, RAM, storage) non dovrebbe essere la prima risposta a problemi di performance. Spesso, un’attenta analisi e ottimizzazione delle configurazioni esistenti possono portare a miglioramenti significativi, con un risparmio economico notevole. Il 73% dei problemi di performance in ambienti virtualizzati può essere risolto senza acquisti hardware, semplicemente ottimizzando le configurazioni (fonte: VMworld Survey 2024).

Ottimizza prima di fare upgrade:

1. Right-sizing delle VM: Assegna solo le risorse necessarie (vCPU, RAM). L’eccesso è inefficiente.
2. Bilanciamento del carico: Utilizza DRS (Distributed Resource Scheduler) o bilancia manualmente le VM tra gli host.
3. Aggiornamento driver/firmware: Assicurati che tutti i componenti hardware dell’host (HBA, NIC) abbiano i driver e firmware più recenti e certificati.
4. Ottimizzazione dello storage: Allineamento delle partizioni, configurazione corretta delle code di I/O, utilizzo di storage tiering.
5. Controlla le impostazioni di power management: Assicurati che l’host ESXi sia configurato per le massime performance, non per il risparmio energetico.

Se dopo tutte queste ottimizzazioni i problemi persistono e le metriche chiave (CPU Ready, Memory Swap, Storage Latency) rimangono a livelli inaccettabili, allora è il momento di considerare un upgrade hardware. Investire in hardware senza una diagnosi precisa è come sparare nel buio: potresti risolvere il problema per caso, ma è più probabile che tu abbia sprecato risorse.

Errori comuni e troubleshooting

• Ignorare i micro-spikes: Un picco di latenza di 100ms per pochi secondi può sembrare innocuo, ma se si ripete centinaia di volte al giorno, degrada l’esperienza utente. Monitora le metriche in modo granulare.
• Over-provisioning eccessivo: Assegnare 16 vCPU a una VM che ne usa 2-4 in media non solo spreca risorse, ma aumenta anche il CPU Ready per gli altri. Cerca sempre di avere un buon rapporto tra vCPU e core fisici (massimo 1:4 o 1:6 in ambienti con carichi elevati).
• Driver e firmware obsoleti: Questo è un classico. Un driver HBA non aggiornato può causare latenze di storage inspiegabili. Controlla sempre la VMware Compatibility Guide (VCG).
• Non capire la correlazione: Un alto CPU Ready potrebbe non essere un problema di CPU, ma un sintomo di storage lento che non alimenta la CPU abbastanza velocemente. Impara a leggere le metriche in relazione tra loro.

FAQ — Domande Frequenti

D: Qual è un valore accettabile di CPU Ready?

R: Generalmente, un valore di CPU Ready inferiore al 5% per una singola VM è considerato sano. Oltre il 10% è un indicatore di gravi problemi di contesa della CPU, che dovrebbero essere indagati immediatamente. In ambienti molto grandi, si può tollerare un 5-10% complessivo, ma non per singole VM critiche.

D: Il Memory Ballooning è sempre un problema?

R: No, il Memory Ballooning è un meccanismo normale e salutare di gestione della memoria in VMware. Diventa un problema solo quando è eccessivo e prolungato, indicando una pressione di memoria tale da compromettere le performance. Monitora il MCTLSZ e se vedi anche attività di SWCUR (swap), la situazione è critica.

D: Come posso verificare se il mio storage è il collo di bottiglia?

R: Utilizza esxtop (schermata ‘d’ per Storage Disk) e i Performance Charts di vCenter. Controlla i valori di DAVG, KAVG, GAVG. Se DAVG è costantemente sopra i 20-30ms, il problema è quasi certamente nel sottosistema di storage. Correlalo con i valori di IOPS e throughput per capire se è un problema di saturazione o di inefficienza.

D: Qual è la differenza tra CPU Ready e CPU Usage?

R: CPU Usage indica quanta CPU la VM sta effettivamente utilizzando. CPU Ready indica per quanto tempo la VM è rimasta in attesa di poter utilizzare la CPU. Una VM può avere CPU Usage basso ma CPU Ready alto: questo significa che è configurata per usare poca CPU, ma anche quella poca che chiede le viene data in ritardo, causando rallentamenti percepiti.

Conclusioni con takeaway operativi

Il troubleshooting delle performance su VMware ESXi richiede un approccio metodico e una comprensione approfondita delle metriche chiave. Concentrarsi su CPU Ready, Memory Ballooning/Swap e Storage Latency ti permetterà di identificare rapidamente i colli di bottiglia e di agire con precisione. Ricorda sempre di ottimizzare le configurazioni e bilanciare i carichi di lavoro prima di considerare costosi upgrade hardware. Utilizza esxtop per l’analisi real-time e vCenter Performance Charts per identificare trend e correlazioni. La capacità di diagnosticare con precisione non solo migliora le performance del tuo ambiente, ma ti rende un asset inestimabile per qualsiasi organizzazione.

Aggiornato: luglio 2026

Leggi anche

Leggi anche: LVM su Linux: Gestione Avanzata dei Volumi Logici — Resize, Snapshot, Migration (2026)

Leggi anche: Docker Sicurezza Produzione: 10 Best Practice Ignorate (2026)

Leggi anche: Prometheus Grafana Monitoring: Checklist Installazione e Alert Critici (2026)