Se amministri un’infrastruttura virtuale basata su VMware vSphere (o qualsiasi altro stack tecnologico), probabilmente sentirai spesso lamentele da parte degli utenti: “La macchina virtuale è lenta!” In questa serie di articoli analizzerò le metriche delle prestazioni e ti dirò cosa e perché rallenta e come assicurarti che non rallenti.
Prenderò in considerazione i seguenti aspetti delle prestazioni della macchina virtuale:
- PROCESSORE,
- RAM,
- DISCO,
- Rete.
Inizierò con la CPU.
Per analizzare le prestazioni avremo bisogno di:
- Contatori delle prestazioni vCenter – contatori delle prestazioni, i cui grafici possono essere visualizzati tramite vSphere Client. Le informazioni su questi contatori sono disponibili in qualsiasi versione del client (client "thick" in C#, client Web in Flex e client Web in HTML5). In questi articoli utilizzeremo gli screenshot del client C#, solo perché sembrano migliori in miniatura :)
- ESXTOP – un'utilità che viene eseguita dalla riga di comando ESXi. Con il suo aiuto è possibile ottenere i valori dei contatori delle prestazioni in tempo reale o caricare questi valori per un determinato periodo in un file .csv per ulteriori analisi. Successivamente, ti dirò di più su questo strumento e fornirò diversi collegamenti utili alla documentazione e agli articoli sull'argomento.
Un po 'di teoria
In ESXi, un processo separato – mondo nella terminologia VMware – è responsabile del funzionamento di ciascuna vCPU (virtual machine core). Esistono anche processi di servizio, ma dal punto di vista dell'analisi delle prestazioni delle VM sono meno interessanti.
Un processo in ESXi può trovarsi in uno dei quattro stati:
- Correre – il processo svolge un lavoro utile.
- Aspetta! – il processo non sta eseguendo alcun lavoro (idle) o è in attesa di input/output.
- Costo – una condizione che si verifica nelle macchine virtuali multi-core. Si verifica quando lo scheduler della CPU dell'hypervisor (ESXi CPU Scheduler) non è in grado di pianificare l'esecuzione simultanea di tutti i core della macchina virtuale attivi sui core del server fisico. Nel mondo fisico, tutti i core del processore funzionano in parallelo, il sistema operativo guest all'interno della VM si aspetta un comportamento simile, quindi l'hypervisor deve rallentare i core della VM che hanno la capacità di completare il ciclo di clock più velocemente. Nelle versioni moderne di ESXi, lo scheduler della CPU utilizza un meccanismo chiamato co-scheduling rilassato: l'hypervisor considera il divario tra il core della macchina virtuale “più veloce” e quello “più lento” (skew). Se il divario supera una certa soglia, il nucleo veloce entra nello stato costop. Se i core delle VM trascorrono molto tempo in questo stato, possono causare problemi di prestazioni.
- Pronto – il processo entra in questo stato quando l'hypervisor non è in grado di allocare risorse per la sua esecuzione. Valori ready elevati possono causare problemi di prestazioni della VM.
Contatori delle prestazioni della CPU della macchina virtuale di base
Uso della CPU, %. Mostra la percentuale di utilizzo della CPU per un determinato periodo.
Come analizzare? Se una VM utilizza costantemente la CPU al 90% o ci sono picchi fino al 100%, allora abbiamo dei problemi. I problemi possono esprimersi non solo nel funzionamento “lento” dell'applicazione all'interno della VM, ma anche nell'inaccessibilità della VM sulla rete. Se il sistema di monitoraggio mostra che la VM periodicamente cade, prestare attenzione ai picchi nel grafico di utilizzo della CPU.
Esiste un allarme standard che mostra il carico della CPU della macchina virtuale:
Cosa fare? Se l'utilizzo della CPU di una VM è costantemente alle stelle, puoi pensare di aumentare il numero di vCPU (sfortunatamente, questo non sempre aiuta) o spostare la VM su un server con processori più potenti.
Utilizzo della CPU in MHz
Nei grafici sull'utilizzo di vCenter in % puoi vedere solo per l'intera macchina virtuale; non ci sono grafici per i singoli core (in Esxtop ci sono valori % per i core). Per ciascun core puoi vedere l'utilizzo in MHz.
Come analizzare? Succede che un'applicazione non è ottimizzata per un'architettura multi-core: utilizza solo un core al 100% e il resto è inattivo senza carico. Ad esempio, con le impostazioni di backup predefinite, MS SQL avvia il processo solo su un core. Di conseguenza, il backup rallenta non a causa della bassa velocità dei dischi (questo è ciò di cui inizialmente si è lamentato l'utente), ma perché il processore non può farcela. Il problema è stato risolto modificando i parametri: il backup ha iniziato a essere eseguito parallelamente in più file (rispettivamente in più processi).
Un esempio di carico irregolare sui core.
Esiste anche una situazione (come nel grafico sopra) in cui i core vengono caricati in modo non uniforme e alcuni di essi presentano picchi del 100%. Come nel caso del caricamento di un solo core, l'allarme per l'utilizzo della CPU non funzionerà (è per l'intera VM), ma si verificheranno problemi di prestazioni.
Cosa fare? Se il software in una macchina virtuale carica i core in modo non uniforme (utilizza solo un core o parte dei core), non ha senso aumentarne il numero. In questo caso è meglio spostare la VM su un server con processori più potenti.
Puoi anche provare a controllare le impostazioni di consumo energetico nel BIOS del server. Molti amministratori abilitano la modalità High Performance nel BIOS e quindi disabilitano le tecnologie di risparmio energetico C-state e P-state. I moderni processori Intel utilizzano la tecnologia Turbo Boost, che aumenta la frequenza dei singoli core del processore a scapito di altri core. Ma funziona solo quando le tecnologie di risparmio energetico sono attive. Se li disabilitiamo, il processore non potrà ridurre il consumo energetico dei core non caricati.
VMware consiglia di non disattivare le tecnologie di risparmio energetico sui server, ma di scegliere modalità che lascino il più possibile la gestione energetica all'hypervisor. In questo caso, nelle impostazioni del consumo energetico dell'hypervisor, è necessario selezionare Prestazioni elevate.
Se nella tua infrastruttura sono presenti singole VM (o core VM) che richiedono una maggiore frequenza della CPU, la corretta regolazione del consumo energetico può migliorare significativamente le loro prestazioni.
CPU pronta
Se il core della VM (vCPU) è nello stato Pronto, non esegue operazioni utili. Questa condizione si verifica quando l'hypervisor non trova un core fisico libero a cui assegnare il processo vCPU della macchina virtuale.
Come analizzare? In genere, se i core di una macchina virtuale sono nello stato Pronto per più del 10% del tempo, si noteranno problemi di prestazioni. In poche parole, più del 10% delle volte la VM attende che le risorse fisiche diventino disponibili.
Nel vCenter è possibile visualizzare 2 contatori relativi a CPU Ready:
- prontezza,
- Pronto.
I valori di entrambi i contatori possono essere visualizzati sia per l'intera VM che per i singoli core.
La disponibilità mostra immediatamente il valore in percentuale, ma solo in tempo reale (dati dell'ultima ora, intervallo di misurazione 20 secondi). È meglio utilizzare questo contatore solo per cercare i problemi “alle calcagna”.
I controvalori pronti possono essere visualizzati anche in una prospettiva storica. Ciò è utile per stabilire modelli e per un'analisi più approfondita del problema. Ad esempio, se una macchina virtuale inizia a riscontrare problemi di prestazioni in un determinato momento, è possibile confrontare gli intervalli del valore CPU pronta con il carico totale sul server su cui è in esecuzione questa VM e adottare misure per ridurre il carico (se DRS non riesce).
Pronto, a differenza della Prontezza, non viene mostrato in percentuale, ma in millisecondi. Si tratta di un contatore di tipo Somma, ovvero mostra per quanto tempo durante il periodo di misurazione il core della VM è rimasto nello stato Pronto. Puoi convertire questo valore in una percentuale utilizzando una semplice formula:
(Valore sommatoria CPU pronta / (intervallo di aggiornamento predefinito del grafico in secondi * 1000)) * 100 = % CPU pronta
Ad esempio, per la VM nel grafico seguente, il valore di picco Pronto per l'intera macchina virtuale sarà il seguente:
Quando calcoli la percentuale di Pronto, dovresti prestare attenzione a due punti:
- Il valore Pronto per l'intera VM è la somma dei valori Pronto tra i core.
- Intervallo di misurazione. Per il tempo reale è di 20 secondi e, ad esempio, sui grafici giornalieri è di 300 secondi.
Con la risoluzione attiva dei problemi, questi semplici punti possono facilmente passare inosservati e si può perdere tempo prezioso nella risoluzione di problemi inesistenti.
Calcoliamo Pronto in base ai dati del grafico sottostante. (324474/(20*1000))*100 = 1622% per l'intera VM. Se guardi i nuclei non è così spaventoso: 1622/64 = 25% per nucleo. In questo caso il problema è abbastanza semplice da individuare: il valore Pronto non è realistico. Ma se parliamo del 10-20% per l'intera VM con più core, per ciascun core il valore potrebbe rientrare nell'intervallo normale.
Cosa fare? Un valore Pronto elevato indica che il server non dispone di risorse del processore sufficienti per il normale funzionamento delle macchine virtuali. In una situazione del genere, non resta che ridurre l'oversubscription del processore (vCPU:pCPU). Ovviamente ciò può essere ottenuto riducendo i parametri delle VM esistenti oppure migrando parte delle VM su altri server.
Co-stop
Come analizzare? Anche questo contatore è del tipo Somma e viene convertito in percentuali allo stesso modo di Pronto:
(Valore sommatoria co-stop CPU / (intervallo di aggiornamento predefinito del grafico in secondi * 1000)) * 100 = % co-stop CPU
Anche in questo caso è necessario prestare attenzione al numero di core sulla VM e all'intervallo di misurazione.
Nello stato costop, il kernel non svolge alcun lavoro utile. Con la corretta selezione della dimensione della macchina virtuale e del carico normale sul server, il contatore di co-stop dovrebbe essere vicino allo zero.
In questo caso, il carico è chiaramente anomalo :)
Cosa fare? Se diverse VM con un numero elevato di core sono in esecuzione su un hypervisor e si verifica un eccesso di sottoscrizione sulla CPU, il contatore co-stop potrebbe aumentare, il che porterà a problemi con le prestazioni di queste VM.
Inoltre, il co-stop aumenterà se i core attivi di una VM utilizzano thread su un core del server fisico con l'hyper-treading abilitato. Questa situazione può verificarsi, ad esempio, se la VM ha più core di quelli fisicamente disponibili sul server su cui è in esecuzione o se l'impostazione "preferHT" è abilitata per la VM. Puoi leggere informazioni su questa impostazione .
Per evitare problemi con le prestazioni della VM dovuti a costi elevati, selezionare la dimensione della VM in conformità con le raccomandazioni del produttore del software in esecuzione su questa VM e con le capacità del server fisico su cui viene eseguita la VM.
Non aggiungere core di riserva; ciò potrebbe causare problemi di prestazioni non solo alla VM stessa, ma anche ai suoi vicini sul server.
Altri parametri utili della CPU
Correre – per quanto tempo (ms) durante il periodo di misurazione la vCPU è rimasta nello stato RUN, ovvero ha effettivamente svolto un lavoro utile.
Idle – per quanto tempo (ms) durante il periodo di misurazione la vCPU è rimasta in uno stato di inattività. Valori di Idle elevati non sono un problema, la vCPU semplicemente non aveva “niente da fare”.
Aspetta! – per quanto tempo (ms) durante il periodo di misurazione la vCPU è rimasta nello stato di Wait. Poiché IDLE è incluso in questo contatore, anche valori di attesa elevati non indicano un problema. Ma se Wait IDLE è basso quando Wait è alto, significa che la VM era in attesa del completamento delle operazioni di I/O e questo, a sua volta, potrebbe indicare un problema con le prestazioni del disco rigido o di eventuali dispositivi virtuali della VM.
Massimo limitato – per quanto tempo (ms) durante il periodo di misurazione la vCPU è rimasta nello stato Pronta a causa del limite di risorse impostato. Se le prestazioni sono inspiegabilmente basse, è utile verificare il valore di questo contatore e il limite della CPU nelle impostazioni della VM. Le VM potrebbero infatti avere limiti di cui non sei a conoscenza. Ciò accade, ad esempio, quando una VM è stata clonata da un modello su cui era impostato il limite della CPU.
Scambia aspetta – quanto tempo durante il periodo di misurazione la vCPU ha atteso un'operazione con VMkernel Swap. Se i valori di questo contatore sono superiori allo zero, allora la VM ha sicuramente problemi di prestazioni. Parleremo più approfonditamente di SWAP nell'articolo sui contatori RAM.
ESXTOP
Se i contatori delle prestazioni in vCenter sono utili per analizzare i dati storici, è meglio eseguire l'analisi operativa del problema in ESXTOP. Qui tutti i valori sono presentati in forma già pronta (non è necessario tradurre nulla) e il periodo di misurazione minimo è di 2 secondi.
La schermata ESXTOP per la CPU si richiama con il tasto "c" e si presenta così:
Per comodità, puoi abbandonare solo i processi della macchina virtuale premendo Shift-V.
Per visualizzare le metriche per i singoli core VM, premi "e" e inserisci il GID della VM di interesse (30919 nello screenshot seguente):
Vorrei esaminare brevemente le colonne presentate per impostazione predefinita. È possibile aggiungere ulteriori colonne premendo "f".
NWLD (Numero di mondi) – numero di processi nel gruppo. Per espandere il gruppo e visualizzare le metriche per ciascun processo (ad esempio, per ciascun core in una VM multi-core), premere "e". Se in un gruppo è presente più di un processo, i valori metrici del gruppo sono uguali alla somma dei valori metrici dei singoli processi.
%USATO – quanti cicli della CPU del server vengono utilizzati da un processo o da un gruppo di processi.
%CORRERE – per quanto tempo durante il periodo di misurazione il processo è rimasto nello stato RUN, ovvero ha fatto un lavoro utile. Si differenzia da %USED in quanto non tiene conto dell'hyper-threading, del ridimensionamento della frequenza e del tempo impiegato nelle attività di sistema (%SYS).
%SIST – tempo impiegato nelle attività di sistema, ad esempio: elaborazione degli interrupt, I/O, funzionamento della rete, ecc. Il valore può essere elevato se la VM ha un I/O di grandi dimensioni.
%OVRLP – quanto tempo il nucleo fisico su cui è in esecuzione il processo VM è dedicato alle attività di altri processi.
Questi parametri sono correlati tra loro come segue:
%USED = %RUN + %SYS - %OVRLP.
In genere la metrica %USED è più informativa.
%ASPETTARE – per quanto tempo durante il periodo di misurazione il processo è rimasto nello stato di attesa. Abilita IDLE.
%OZIARE – per quanto tempo durante il periodo di misurazione il processo è rimasto nello stato IDLE.
%SWPWT – quanto tempo durante il periodo di misurazione la vCPU ha atteso un'operazione con VMkernel Swap.
%VMATTESA – quanto tempo durante il periodo di misurazione la vCPU è rimasta nello stato di attesa di un evento (solitamente I/O). Non esiste un contatore simile in vCenter. Valori elevati indicano problemi con l'I/O sulla VM.
%ATTESA = %VMWAIT + %IDLE + %SWPWT.
Se la VM non utilizza VMkernel Swap, quando si analizzano i problemi di prestazioni è consigliabile guardare %VMWAIT, poiché questa metrica non tiene conto del tempo in cui la VM non faceva nulla (%IDLE).
%RDY – per quanto tempo durante il periodo di misurazione il processo è rimasto nello stato Pronto.
%CSTP – per quanto tempo durante il periodo di misurazione il processo è rimasto nello stato costop.
%MLMTD – per quanto tempo durante il periodo di misurazione la vCPU è rimasta nello stato Pronta a causa del limite di risorse impostato.
%WAIT + %RDY + %CSTP + %RUN = 100% – il core della VM è sempre in uno di questi quattro stati.
CPU sull'hypervisor
vCenter dispone anche di contatori delle prestazioni della CPU per l'hypervisor, ma non sono nulla di interessante: sono semplicemente la somma dei contatori di tutte le VM sul server.
Il modo più conveniente per visualizzare lo stato della CPU sul server è nella scheda Riepilogo:
Per il server, così come per la macchina virtuale, esiste un allarme standard:
Quando il carico della CPU del server è elevato, le macchine virtuali in esecuzione su di esso iniziano a riscontrare problemi di prestazioni.
In ESXTOP, i dati sul carico della CPU del server vengono presentati nella parte superiore dello schermo. Oltre al carico standard della CPU, che non è molto informativo per gli hypervisor, ci sono altri tre parametri:
UTILE PRINCIPALE(%) – caricamento del core del server fisico. Questo contatore mostra per quanto tempo il nucleo ha eseguito il lavoro durante il periodo di misurazione.
UTIL PCPU(%) – se l'hyper-threading è abilitato, allora ci sono due thread (PCPU) per core fisico. Questa metrica mostra quanto tempo ha impiegato ciascun thread per completare il lavoro.
PCPU UTILIZZATA(%) – uguale a PCPU UTIL(%), ma tiene conto del ridimensionamento della frequenza (riducendo la frequenza core per scopi di risparmio energetico o aumentando la frequenza core grazie alla tecnologia Turbo Boost) e l'hyper-threading.
PCPU_USED% = PCPU_UTIL% * frequenza core effettiva / frequenza core nominale.
In questo screenshot, per alcuni core, a causa del Turbo Boost, il valore USED è maggiore del 100%, poiché la frequenza del core è superiore a quella nominale.
Qualche parola su come viene preso in considerazione l'hyper-threading. Se i processi vengono eseguiti il 100% delle volte su entrambi i thread del core fisico del server, mentre il core opera alla frequenza nominale, allora:
- CORE UTIL per il core sarà 100%,
- L'UTIL PCPU per entrambi i thread sarà 100%,
- La PCPU USATA per entrambi i thread sarà del 50%.
Se entrambi i thread non hanno funzionato il 100% delle volte durante il periodo di misurazione, durante i periodi in cui i thread hanno funzionato in parallelo, la PCPU UTILIZZATA per i core viene divisa a metà.
ESXTOP dispone anche di una schermata con i parametri di consumo energetico della CPU del server. Qui puoi vedere se il server utilizza tecnologie di risparmio energetico: stati C e stati P. Chiamato con il tasto "p":
Problemi comuni di prestazioni della CPU
Infine, esaminerò le cause tipiche dei problemi con le prestazioni della CPU della VM e fornirò brevi suggerimenti per risolverli:
La velocità del core clock non è sufficiente. Se non è possibile aggiornare la tua VM a core più potenti, puoi provare a modificare le impostazioni di alimentazione per far funzionare Turbo Boost in modo più efficiente.
Dimensionamento della VM errato (troppi/pochi core). Se installi pochi core, ci sarà un carico elevato della CPU sulla VM. Se c'è molto, prendi un co-stop alto.
Grande sottoscrizione eccessiva di CPU sul server. Se la VM ha un valore Pronto elevato, riduci la sottoscrizione eccessiva della CPU.
Topologia NUMA errata su VM di grandi dimensioni. La topologia NUMA vista dalla VM (vNUMA) deve corrispondere alla topologia NUMA del server (pNUMA). La diagnostica e le possibili soluzioni a questo problema sono scritte, ad esempio, nel libro . Se non vuoi andare più in profondità e non hai restrizioni di licenza sul sistema operativo installato sulla VM, crea molti socket virtuali sulla VM, un core alla volta. Non perderai molto :)
Questo è tutto per me riguardo alla CPU. Fare domande. Nella parte successiva parlerò della RAM.
Link utili
Fonte: habr.com