Se amministrate una infrastruttura virtuale basata in VMware vSphere (o qualsiasi altra pila di tecnulugia), probabilmente sentiate spessu lagnanze da l'utilizatori: "A macchina virtuale hè lenta!" In questa serie di articuli analizaraghju e metriche di rendiment è vi dicu ciò chì è perchè rallenta è cumu per assicurà chì ùn rallenta micca.
Cunsidereraghju i seguenti aspetti di u rendiment di a macchina virtuale:
- CPU,
- FRAME,
- DISCU,
- Network.
Cumincià cù u CPU.
Per analizà u rendiment, avemu bisognu di:
- vCenter Performance Counters - cuntatori di rendiment, chì i grafici ponu esse visti attraversu u Client vSphere. L'infurmazione nantu à questi cuntatori hè dispunibule in ogni versione di u cliente (cliente "grossu" in C#, client web in Flex è client web in HTML5). In questi articuli useremu screenshots da u cliente C#, solu perchè parenu megliu in miniatura :)
- ESXTOP - una utilità chì corre da a linea di cummanda ESXi. Cù u so aiutu, pudete uttene i valori di i cuntatori di prestazione in tempu reale o caricate questi valori per un certu periodu in un schedariu .csv per più analisi. In seguitu, vi dicu più nantu à questu strumentu è furnisce parechji ligami utili à documentazione è articuli nantu à u tema.
Un pocu di tiurìa
In ESXi, un prucessu separatu - u mondu in a terminologia VMware - hè rispunsevule per l'operazione di ogni vCPU (core virtual machine). Ci sò ancu prucessi di serviziu, ma da u puntu di vista di l'analisi di u rendiment VM sò menu interessanti.
Un prucessu in ESXi pò esse in unu di quattru stati:
- Run - u prucessu faci un travagliu utile.
- Aspettate - u prucessu ùn hè micca fattu un travagliu (inattivu) o aspetta per input / output.
- Costop - una cundizione chì si trova in macchine virtuali multi-core. Succece quandu l'ipervisore CPU Scheduler (ESXi CPU Scheduler) ùn pò micca pianificà l'esekzione simultanea di tutti i nuclei di a macchina virtuale attiva nantu à i nuclei di u servitore fisicu. In u mondu fisicu, tutti i nuclei di u processatore funzionanu in parallelu, u SO invitatu in a VM aspetta un cumpurtamentu simili, cusì l'ipervisore hà da rallentà i core VM chì anu a capacità di finisce u so ciclu di clock più veloce. In e versioni muderni di ESXi, u pianificatore di CPU usa un mecanismu chjamatu co-scheduling rilassatu: l'ipervisore cunsidereghja a distanza trà u core di a macchina virtuale "più veloce" è "più lento" (skew). Se u gap supera un certu limitu, u core veloce entra in u statu di costop. Se i core VM passanu assai tempu in questu statu, pò causà prublemi di rendiment.
- Animu - u prucessu entra in questu statu quandu l'ipervisore ùn hè micca capaci di assignà risorse per a so esicuzzioni. Alti valori pronti ponu causà prublemi di rendiment VM.
Contatori di prestazioni di CPU di a macchina virtuale di basa
Usu CPU, %. Mostra u percentualità di usu di CPU per un periodu determinatu.
Cumu analizà? Se una VM usa constantemente CPU à 90% o ci sò picchi finu à 100%, allora avemu prublemi. I prublemi ponu esse spressi micca solu in l'operazione "lenta" di l'applicazione in a VM, ma ancu in l'inaccessibilità di a VM nantu à a reta. Se u sistema di surviglianza mostra chì a VM periodicamente cade, fate attenzione à i picchi in u graficu di l'Usu CPU.
Ci hè un Alarm standard chì mostra a carica di CPU di a macchina virtuale:
Chì deve fà? Se l'Usu di CPU di una VM passa in permanenza per u tettu, pudete pensà à aumentà u nùmeru di vCPU (sfurtunatamente, questu ùn hè micca sempre aiutu) o trasladà a VM à un servitore cù processori più putenti.
Usu CPU in MHz
In i grafici nantu à vCenter Usage in % pudete vede solu per tutta a macchina virtuale; ùn ci sò micca grafici per i nuclei individuali (in Esxtop ci sò % valori per i nuclei). Per ogni core pudete vede Usage in MHz.
Cumu analizà? Succede chì una applicazione ùn hè micca ottimizzata per una architettura multi-core: usa solu un core 100%, è u restu hè inattivu senza carica. Per esempiu, cù i paràmetri di salvezza predeterminati, MS SQL principia u prucessu nantu à un solu core. In u risultatu, a copia di salvezza rallenta micca per via di a veloce veloce di i dischi (questu hè ciò chì l'utilizatore inizialmente si lamentava), ma perchè u processatore ùn pò micca affruntà. U prublema hè stata risolta da cambià i paràmetri: a copia di salvezza hà cuminciatu à curriri in parallelu in parechji schedari (rispettivamente, in parechji prucessi).
Un esempiu di carica irregolari nantu à i core.
Ci hè ancu una situazione (cum'è in u graficu sopra) quandu i nuclei sò caricati in modu irregulare è alcuni di elli anu picchi di 100%. Cum'è a carica di un solu core, l'alarma per l'Usu CPU ùn funziona micca (hè per tutta a VM), ma ci saranu prublemi di rendiment.
Chì deve fà? Se u software in una macchina virtuale carica i nuclei in modu irregulare (utilice solu un core o parte di i nuclei), ùn ci hè nunda di aumentà u so numeru. In questu casu, hè megliu trasfurmà a VM à un servitore cù processori più putenti.
Pudete ancu pruvà à verificà i paràmetri di cunsumu di energia in u BIOS di u servitore. Parechji amministratori attivanu u modalità High Performance in u BIOS è cusì disattiveghjanu e tecnulugia di risparmiu energeticu di stati C è P-states. I prucessori Intel muderni utilizanu a tecnulugia Turbo Boost, chì aumenta a freccia di i nuclei di processori individuali à a spesa di l'altri core. Ma funziona solu quandu e tecnulugia di risparmiu d'energia sò attivate. Se li disattivemu, u processatore ùn pò micca riduce u cunsumu di energia di i core chì ùn sò micca carricati.
VMware ricumanda micca di disattivà e tecnulugia di risparmiu di energia in i servitori, ma di sceglie modi chì lascianu a gestione di l'energia à l'ipervisore quantu pussibule. In questu casu, in i paràmetri di cunsumu d'energia di l'ipervisore, avete bisognu di selezziunà High Performance.
Se tenete VM individuali (o core VM) in a vostra infrastruttura chì necessitanu una frequenza di CPU aumentata, l'aghjustà currettamente u cunsumu di energia pò migliurà significativamente u so rendiment.
CPU Ready
Se u core VM (vCPU) hè in u statu Ready, ùn faci micca un travagliu utile. Sta cundizione si trova quandu l'ipervisore ùn trova micca un core fisicu liberu à quale u prucessu vCPU di a macchina virtuale pò esse assignatu.
Cumu analizà? Di genere, se i nuclei di una macchina virtuale sò in u statu Ready più di 10% di u tempu, noterete prublemi di rendiment. Bastamente, più di u 10% di u tempu chì a VM aspetta chì e risorse fisiche sò dispunibili.
In vCenter pudete vede 2 contatori ligati à CPU Ready:
- prontezza,
- Prestu.
I valori di i dui contatori ponu esse visti sia per tutta a VM sia per i core individuali.
A prontezza mostra immediatamente u valore in percentuale, ma solu in tempu Reale (dati per l'ultima ora, intervallu di misurazione 20 seconde). Hè megliu aduprà stu contatore solu per circà i prublemi "caldi nantu à i tacchi".
I valori di contatore pronti ponu ancu esse vistu da una perspettiva storica. Questu hè utile per stabilisce mudelli è per una analisi più profonda di u prublema. Per esempiu, se una macchina virtuale cumencia à sperimentà prublemi di rendiment à un certu tempu, pudete paragunà l'intervalli di u valore CPU Ready cù a carica tutale in u servitore induve sta VM hè in esecuzione, è piglià misure per riduce a carica (se DRS). falla).
Ready, à u cuntrariu di Readiness, ùn hè micca mostratu in percentuali, ma in millisecondi. Questu hè un contatore di tipu Summation, vale à dì, mostra quantu longu durante u periodu di misurazione u core VM era in u statu Ready. Pudete cunvertisce stu valore in un percentinu cù una formula simplice:
(Valore di somma di CPU pronta / (intervallu di aghjurnamentu predeterminatu di u graficu in seconde * 1000)) * 100 = CPU pronta %
Per esempiu, per a VM in u graficu quì sottu, u valore piccu Ready per tutta a macchina virtuale serà cusì:
Quandu si calcula u percentualità Ready, duvete attentu à dui punti:
- U valore Ready per tutta a VM hè a somma di Ready attraversu i core.
- Intervallu di misurazione. Per Real-time hè 20 seconde, è, per esempiu, nantu à i grafici di ogni ghjornu hè 300 seconde.
Cù risoluzione di prublemi attiva, questi punti simplici ponu esse facilmente mancati è un tempu preziosu pò esse persu per risolve i prublemi inesistenti.
Calculemu Ready basatu nantu à i dati da u graficu sottu. (324474/(20*1000))*100 = 1622% per tutta a VM. Se fighjate à i nuclei ùn hè micca cusì spaventoso: 1622/64 = 25% per core. In questu casu, a cattura hè abbastanza faciule per spot: u valore Ready ùn hè micca realisticu. Ma se parlemu di 10-20% per tutta a VM cù parechji nuclei, allora per ogni core u valore pò esse in u range normale.
Chì deve fà? Un altu valore Ready indica chì u servitore ùn hà micca abbastanza risorse di processore per u funziunamentu normale di e macchine virtuali. In una tale situazione, tuttu ciò chì resta hè di riduce l'oversubscription per processore (vCPU: pCPU). Ovviamente, questu pò esse ottenutu riducendu i paràmetri di VM esistenti o migrando parte di e VM à altri servitori.
Co-stop
Cumu analizà? Stu contatore hè ancu di u tipu di Summazione è hè cunvertitu in percentuali in u listessu modu chì Ready:
(Valore di somma di co-stop CPU / (intervallu di aghjurnamentu predeterminatu di u graficu in seconde * 1000)) * 100 = % di co-stop CPU
Quì hè ancu bisognu di attentu à u numeru di core nantu à a VM è l'intervallu di misurazione.
In u statu di costop, u kernel ùn faci micca un travagliu utile. Cù a selezzione curretta di a dimensione VM è a carica normale nantu à u servitore, u cuntatore di co-stop deve esse vicinu à cero.
In questu casu, a carica hè chjaramente anormale :)
Chì deve fà? Sì parechji VM cù un gran numaru di core sò in esecuzione nantu à un hypervisor è ci hè una sottoscrizione eccessiva in u CPU, allura u cuntatore di co-stop pò aumentà, chì porta à prublemi cù u rendiment di sti VM.
Inoltre, u co-stop aumenterà se i core attivi di una VM utilizanu fili in un core di u servitore fisicu cù l'iper-treading attivatu. Questa situazione pò esse, per esempiu, se a VM hà più nuclei chì fisicamenti dispunibuli nantu à u servitore induve hè in esecuzione, o se l'impostazione "preferHT" hè attivata per a VM. Pudete leghje nantu à questu paràmetru .
Per evità prublemi cù u rendiment di VM per via di un altu co-stop, selezziunate a dimensione di VM in cunfurmità cù i cunsiglii di u fabricatore di u software chì corre nantu à questa VM è e capacità di u servitore fisicu induve a VM corre.
Ùn aghjunghje micca core in riserva; questu pò causà prublemi di rendiment micca solu per a VM stessu, ma ancu per i so vicini in u servitore.
Altre metriche di CPU utili
Run - quantu tempu (ms) durante u periodu di misurazione, u vCPU era in u statu RUN, vale à dì, era in realtà eseguisce un travagliu utile.
Idle - quantu tempu (ms) durante u periodu di misurazione a vCPU era in un statu di inattività. Alti valori Idle ùn sò micca un prublema, a vCPU ùn avia solu "nunda à fà".
Aspettate - quantu tempu (ms) durante u periodu di misurazione, u vCPU era in u statu di aspittà. Siccomu IDLE hè inclusu in questu contatore, i valori elevati di aspittà ùn indicanu micca ancu un prublema. Ma se Wait IDLE hè bassu quandu Wait hè altu, significa chì a VM era aspittendu chì l'operazioni I / O finiscinu, è questu, à u turnu, pò indicà un prublema cù u rendiment di u discu duru o qualsiasi dispositi virtuali di a VM.
Massimu limitatu - quantu tempu (ms) durante u periodu di misurazione, a vCPU era in u statu Ready per via di u limitu di risorse stabilitu. Se u rendiment hè inspiegabilmente bassu, allora hè utile per verificà u valore di stu contatore è u limitu CPU in i paràmetri VM. I VM pò daveru avè limiti chì ùn site micca cunnisciutu. Per esempiu, questu succede quandu una VM hè stata clonata da un mudellu nantu à quale u limitu CPU hè statu stabilitu.
Scambià aspetta - quantu tempu durante u periodu di misurazione a vCPU hà aspittatu per una operazione cù VMkernel Swap. Se i valori di stu contatore sò sopra à cero, allora a VM hà definitivamente prublemi di rendiment. Parleremu più nantu à SWAP in l'articulu di i contatori di RAM.
ESXTOP
Se i contatori di rendiment in vCenter sò boni per analizà e dati storichi, allora l'analisi operativa di u prublema hè megliu fattu in ESXTOP. Quì, tutti i valori sò presentati in forma pronta (ùn hè bisognu di traduce nunda), è u periodu minimu di misurazione hè di 2 seconde.
A pantalla ESXTOP per CPU hè chjamata cù a chjave "c" è pare cusì:
Per comodità, pudete lascià solu i prucessi di a macchina virtuale premendu Shift-V.
Per vede e metriche per i nuclei VM individuali, premete "e" è inserite u GID di a VM d'interessu (30919 in a screenshot sottu):
Lasciami passà brevemente per e culonne chì sò presentati per difettu. Culonni supplementari ponu esse aghjuntu pressu "f".
NWLD (Number of Worlds) - numeru di prucessi in u gruppu. Per espansione u gruppu è vede metriche per ogni prucessu (per esempiu, per ogni core in una VM multi-core), press "e". Se ci hè più di un prucessu in un gruppu, i valori metrici per u gruppu sò uguali à a summa di e metriche per i prucessi individuali.
% USATE - quantu ciculi di CPU di u servitore sò utilizati da un prucessu o gruppu di prucessi.
% RUN – quantu tempu durante u periodu di misurazione u prucessu era in u statu RUN, i.e. hà fattu un travagliu utile. Differisce da %USED in quantu ùn piglia micca in contu l'iper-threading, a scala di freccia è u tempu spentu in i travaglii di u sistema (%SYS).
%SYS - tempu spentu nantu à i travaglii di u sistema, per esempiu: interruzzione di trasfurmazioni, I / O, operazione di rete, etc. U valore pò esse altu se a VM hà una grande I / O.
% OVRLP - quantu tempu u core fisicu nantu à quale u prucessu VM hè in esecuzione hà spesu nantu à i travaglii di altri prucessi.
Queste metriche sò in relazione trà elli cum'è seguita:
%USED = %RUN + %SYS - %OVRLP.
Di genere, a metrica %USED hè più informativa.
% ASPETTA - quantu tempu durante u periodu di misurazione u prucessu era in u statu di aspittà. Attiva IDLE.
%IDLE - quantu tempu durante u periodu di misurazione u prucessu era in u statu IDLE.
%SWPWT - quantu tempu durante u periodu di misurazione a vCPU hà aspittatu per una operazione cù VMkernel Swap.
%VMWAIT - quantu tempu durante u periodu di misurazione a vCPU era in u statu di aspittà per un avvenimentu (in solitu I/O). Ùn ci hè micca un contatore simili in vCenter. Alti valori indicanu prublemi cù I / O in a VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Se a VM ùn usa micca VMkernel Swap, allora quandu analizà i prublemi di rendiment hè cunsigliatu di guardà %VMWAIT, postu chì sta metrica ùn piglia micca in contu u tempu quandu a VM ùn facia nunda (%IDLE).
%RDY - quantu tempu durante u periodu di misurazione u prucessu era in u statu Ready.
%CSTP - quantu tempu durante u periodu di misurazione u prucessu era in u statu di costop.
%MLMTD - quantu tempu durante u periodu di misurazione u vCPU era in u statu Ready per via di u limitu di risorse stabilitu.
%WAIT + %RDY + %CSTP + %RUN = 100% - u core VM hè sempre in unu di sti quattru stati.
CPU nantu à ipervisore
vCenter hà ancu cuntatori di rendiment di CPU per l'ipervisore, ma ùn sò nunda di interessante - sò solu a summa di i contatori per tutti i VM in u servitore.
A manera più còmuda di vede u statu di CPU in u servitore hè nantu à a tabulazione Riassuntu:
Per u servitore, è ancu per a macchina virtuale, ci hè un Alarm standard:
Quandu a carica di CPU di u servitore hè alta, i VM in esecuzione cumincianu à sperimentà prublemi di rendiment.
In ESXTOP, i dati di carica di CPU di u servitore sò presentati in cima di u screnu. In più di a carica standard di CPU, chì ùn hè micca assai informativa per ipervisori, ci sò trè metrichi più:
CORE UTIL (%) - carica u core di u servitore fisicu. Stu contatore mostra quantu tempu u core hà fattu u travagliu durante u periodu di misurazione.
UTIL PCPU (%) - se l'iper-threading hè attivatu, allora ci sò dui fili (PCPU) per core fisicu. Questa metrica mostra quantu tempu ogni filu hà pigliatu per finisce u travagliu.
PCPU USED (%) - u listessu cum'è PCPU UTIL(%), ma piglia in contu u scaling di freccia (sia riducendu a freccia core per scopi di risparmiu d'energia, sia cresce a frequenza core per via di a tecnulugia Turbo Boost) è iper-threading.
PCPU_USED% = PCPU_UTIL% * frequenza core effettiva / frequenza nominale core.
In questa screenshot, per certi nuclei, per via di Turbo Boost, u valore USED hè più grande di 100%, postu chì a frequenza di u core hè più altu ch'è u nominale.
Uni pochi di parolle nantu à cumu l'iper-threading hè cunsideratu. Se i prucessi sò eseguiti 100% di u tempu nantu à i dui fili di u core fisicu di u servitore, mentre chì u core opera à a freccia nominale, allora:
- CORE UTIL per u core serà 100%,
- PCPU UTIL per i dui fili serà 100%,
- PCPU USED per i dui fili serà 50%.
Sì i dui fili ùn anu micca travagliatu 100% di u tempu durante u periodu di misurazione, allora durante quelli periodi chì i filamenti travagliavanu in parallelu, u PCPU USED per i core hè divisu à a mità.
ESXTOP hà ancu una schermu cù i paràmetri di cunsumu di energia CPU di u servitore. Quì pudete vede se u servitore usa tecnulugia di risparmiu d'energia: C-states è P-states. Chjamatu cù a chjave "p":
Problemi cumuni di rendiment di CPU
Infine, andaraghju nantu à e cause tipiche di prublemi cù u rendiment di CPU VM è dà cunsiglii brevi per risolve:
A velocità di u clock core ùn hè micca abbastanza. Se ùn hè micca pussibule di aghjurnà a vostra VM à core più putenti, pudete pruvà à cambià i paràmetri di putenza per fà chì Turbo Boost travaglia in modu più efficace.
Sizing VM incorrecte (troppu / pochi core). Se installate pochi core, ci sarà una alta carica di CPU nantu à a VM. Se ci hè assai, pigliate un altu co-stop.
Grande oversubscription di CPU nantu à u servitore. Se a VM hà un altu Ready, riduce l'oversubscription CPU.
Topulugia NUMA incorretta nantu à grandi VM. A topologia NUMA vista da a VM (vNUMA) deve currisponde à a topologia NUMA di u servitore (pNUMA). Diagnostics è pussibuli suluzioni à stu prublema sò scritti, per esempiu, in u libru . Se ùn vulete micca più profonda è ùn avete micca restrizioni di licenze nantu à u SO installatu nantu à a VM, fate assai sockets virtuali nantu à a VM, un core à volta. Ùn perderete micca assai :)
Hè tuttu per mè nantu à u CPU. Fate dumande. In a prossima parte vi parleraghju di RAM.
E ligami utili
Source: www.habr.com