Dacă gestionați o infrastructură virtuală bazată pe VMware vSphere (sau orice altă tehnologie similară), este foarte probabil să auziți adesea din partea utilizatorilor plângeri de genul: „Mașina virtuală funcționează lent!”. În acest ciclu de articole voi analiza metricile de performanță și voi explica ce anume „încetinește” și cum se poate face pentru a nu mai fi „încet”.
Voi analiza următoarele aspecte ale performanței mașinilor virtuale:
- CPU,
- RAM,
- DISK,
- Rețea.
Voi începe cu CPU.
Pentru a analiza performanța, avem nevoie de:
- vCenter Performance Counters – contoare de performanță, graficele cărora pot fi vizualizate prin vSphere Client. Informațiile disponibile pentru aceste contoare pot fi accesate în orice versiune a clientului (client „gros” pe C#, web-client pe Flex și web-client pe HTML5). În aceste articole, vom utiliza capturi de ecran din clientul C#, doar pentru că arată mai bine în miniatură:)
- ESXTOP – un instrument care se pornește din linia de comandă ESXi. Prin acesta, se pot obține valorile contoarelor de performanță în timp real sau se pot exporta aceste valori pe o anumită perioadă într-un fișier .csv pentru analize ulterioare. Voi descrie acest instrument în detaliu și voi oferi câteva linkuri utile către documentație și articole pe acest subiect.
Puțină teorie
În ESXi, fiecare vCPU (nucleu al mașinii virtuale) este gestionat de un proces separat – world în terminologia VMware. Există, de asemenea, procese de sistem, dar din perspectiva analizei performanței VM-ului, acestea sunt mai puțin interesante.
Un proces în ESXi poate fi în una dintre cele patru stări:
- Run – procesul efectuează o activitate utilă.
- Wait – procesul nu efectuează nicio activitate (inactiv) sau așteaptă intrare/ieșire.
- Costop – o stare care apare în mașinile virtuale multicores. Aceasta se produce atunci când scheduler-ul CPU al hypervisor-ului (ESXi CPU Scheduler) nu poate planifica execuția simultană pe nucleele fizice ale serverului pentru toate nucleele active ale mașinii virtuale. În lumea fizică, toate nucleele procesorului funcționează în paralel, sistemul de operare invitat din MV se bazează pe un comportament similar, așa că hypervisor-ul trebuie să încetinească nucleele MV-ului care pot termina ciclul mai repede. În versiunile moderne ale ESXi, scheduler-ul CPU utilizează un mecanism numit co-scheduling relaxat: hypervisor-ul consideră diferența dintre cel mai „rapid” și cel mai „lent” nucleu al mașinii virtuale (skew). Dacă diferența depășește un anumit prag, nucleul „rapid” intră în starea costop. Dacă nucleele MV-ului petrec mult timp în această stare, acest lucru poate provoca probleme de performanță.
- Gata – procesul trece în această stare atunci când hypervisor-ul nu are posibilitatea de a aloca resurse pentru executarea sa. Valorile mari ale ready pot provoca probleme de performanță ale MV-ului.
Principalele contoare de performanță CPU ale mașinii virtuale
Utilizarea CPU, %. Afișează procentul de utilizare a CPU-ului pe o perioadă dată.
Cum să analizați? Dacă MV-ul utilizează constant CPU-ul la 90% sau există vârfuri de până la 100%, atunci avem probleme. Problemele pot fi exprimate nu doar prin „încetinirea” funcționării aplicației din interiorul MV-ului, ci și prin inaccesibilitatea MV-ului în rețea. Dacă sistemul de monitorizare arată că MV-ul pică periodic, atenție la vârfurile din graficul Utilizării CPU.
Există o alarmă standard care arată încărcarea CPU-ului mașinii virtuale:
Ce să fac? Dacă utilizarea CPU-ului la MV depășește constant limitele, atunci ar trebui să ne gândim la creșterea numărului de vCPU (din păcate, acest lucru nu ajută întotdeauna) sau la mutarea MV-ului pe un server cu procesoare mai performante.
Utilizarea CPU în MHz
În graficele din vCenter, Utilizarea în % se poate vizualiza doar pentru întreaga mașină virtuală, nu există grafice pentru nuclele individuale (în Esxtop există valori în % pe nuclee). Pentru fiecare nucleu, se poate vizualiza Utilizarea în MHz.
Cum să analizați? Există situații în care aplicația nu este optimizată pentru arhitectura multi-core: folosește 100% doar un singur nucleu, iar celelalte rămân inactive. De exemplu, cu setările implicite de backup, MS SQL pornește procesul doar pe un nucleu. În consecință, backup-ul este încetinit nu din cauza vitezei reduse a discurilor (la asta s-a plâns inițial utilizatorul), ci din cauza procesorului care nu face față. Problema a fost rezolvată modificând parametrii: backup-ul a început să se desfășoare în paralel în mai multe fișiere (prin urmare, în mai multe procese).
Exemplu de încărcare inegală a nucleelor.
De asemenea, există situații (așa cum se vede în graficul de mai sus), când nucleele sunt încărcate inegal și unele dintre ele au vârfuri de 100%. La fel ca în cazul încărcării doar a unui singur nucleu, alarma privind utilizarea CPU nu se va activa (deoarece se aplică pentru întreaga VM), dar vor exista probleme de performanță.
Ce să fac? Dacă software-ul din mașina virtuală încarcă nucleele inegal (folosește doar un nucleu sau o parte din nuclee), nu are sens să crești numărul acestora. În acest caz, ar fi mai bine să muți VM-ul pe un server cu procesoare mai performante.
De asemenea, se poate verifica setările de consum de energie din BIOS-ul serverului. Mulți administratori activează în BIOS modul High Performance, dezactivând astfel tehnologiile de economisire a energiei C-states și P-states. În procesoarele Intel moderne se utilizează tehnologia Turbo Boost, care crește frecvența anumitor nuclee ale procesorului pe seama altora. Dar aceasta funcționează doar cu tehnologiile de economisire a energiei activate. Dacă le dezactivăm, procesorul nu poate reduce consumul de energie al nucleelor care nu sunt încărcate.
VMware recomandă să nu dezactivați tehnologiile de economisire a energiei pe servere, ci să alegeți moduri care lasă controlul consumului de energie hipervizorului. În acest caz, în setările de consum de energie ale hipervizorului, trebuie selectat modul High Performance.
Dacă în infrastructura dumneavoastră există VM-uri separate (sau nuclee VM) care necesită o frecvență CPU crescută, configurarea corectă a consumului de energie poate îmbunătăți semnificativ performanța acestora.
CPU Ready (Readiness)
Dacă nucleul VM (vCPU) se află în starea Ready, acesta nu își îndeplinește sarcina utilă. Această stare apare când hipervizorul nu găsește un nucleu fizic liber pe care să poată aloca procesul vCPU al mașinii virtuale.
Cum să analizați? De obicei, dacă nuclee ale mașinii virtuale se află în starea Ready mai mult de 10% din timp, veți observa probleme de performanță. Cu alte cuvinte, mai mult de 10% din timp, VM așteaptă disponibilitatea resurselor fizice.
În vCenter, puteți vedea 2 contoare legate de CPU Ready:
- Readiness,
- Ready.
Valorile ambelor contoare pot fi vizualizate atât pentru întreaga VM, cât și pentru nuclee individuale.
Readiness arată valoarea imediat în procente, dar doar în timp real (datele din ultima oră, intervalul de măsurare de 20 de secunde). Acest contor este cel mai bine utilizat doar pentru identificarea problemelor 'pe punctul de a se întâmpla'.
Valorile contorului Ready pot fi de asemenea verificate dintr-o perspectivă istorică. Acest lucru este util pentru a identifica tipare și pentru o analiză mai profundă a problemei. De exemplu, dacă o mașină virtuală începe să aibă probleme de performanță într-un anumit moment, se pot compara intervalele de timp cu valori ridicate ale CPU Ready cu încărcarea generală a serverului pe care această VM funcționează, și se pot lua măsuri pentru reducerea încărcării (dacă DRS nu a reușit).
Ready, spre deosebire de Readiness, se afișează nu în procente, ci în milisecunde. Acesta este un contor de tip Summation, ceea ce înseamnă că arată cât timp, pe parcursul intervalului măsurării, nucleul VM a fost în starea Ready. Această valoare poate fi transformată în procente cu o formulă simplă:
(valoarea de summare CPU ready / (intervalul de actualizare implicit al graficului în secunde * 1000)) * 100 = CPU ready %
De exemplu, pentru VM-ul din graficul de mai jos, valoarea maximă a Ready pentru întreaga mașină virtuală va fi următoarea:
Când calculați valoarea Ready în procente, este important să luați în considerare două aspecte:
- Valoarea Ready pentru întreaga VM este suma Ready pentru nuclee.
- Intervalul de măsurare. Pentru timp real – acesta este de 20 de secunde, iar, de exemplu, pentru graficele zilnice – acesta este de 300 de secunde.
În timpul unei depanări active, aceste momente simple pot fi ușor omise, economisind timp prețios în rezolvarea problemelor inexistente.
Vom calculăm Ready pe baza datelor din graficul de mai jos. (324474/(20*1000))*100 = 1622% pentru întreaga VM. Dacă ne uităm pe nuclee, situația devine mai puțin alarmantă: 1622/64 = 25% pe nucă. În acest caz, descoperirea capcanei este destul de simplă: valoarea Ready este nerealistă. Dar dacă ne referim la 10-20% pentru întreaga VM cu mai multe nuclee, atunci pentru fiecare nucă valoarea poate fi în limite normale.
Ce să fac? O valoare ridicată a Ready indică faptul că serverul nu dispune de suficiente resurse CPU pentru a funcționa corect mașinile virtuale. În această situație, rămâne doar să reduceți supra-înscrierea pe procesor (vCPU:pCPU). Evident, acest lucru poate fi realizat prin micșorarea parametrilor mașinilor virtuale existente sau prin migrarea unor VM pe alte servere.
Co-stop
Cum să analizați? Acest contoar are, de asemenea, tipul Summation și se convertește în procente în mod similar cu Ready:
(valoarea sumării co-stop CPU / (intervalul de actualizare implicit al graficului în secunde * 1000)) * 100 = % co-stop CPU
Aici, de asemenea, trebuie să se acorde atenție numărului de nuclee pe VM și intervalului de măsurare.
În starea co-stop, nuca nu efectuează muncă utilă. Cu o dimensionare corectă a VM-ului și o sarcină normală pe server, conta co-stop ar trebui să fie aproape de zero.
În acest caz, sarcina este clar anormală :)
Ce să fac? Dacă pe un singur hypervizor funcționează mai multe VM-uri cu un număr mare de nuclee și există o supra-înscriere pe CPU, atunci contorul co-stop poate crește, ceea ce va duce la probleme de performanță pentru aceste VM-uri.
De asemenea, co-stop va crește dacă pentru nucleele active ale unei VM sunt utilizate fire pe un singur nucleu fizic al serverului cu hyper-threading activat. O astfel de situație poate apărea, de exemplu, dacă VM are mai multe nuclee decât există fizic pe serverul pe care rulează, sau dacă pentru VM este activată setarea «preferHT». Despre această setare puteți citi .
Pentru a evita problemele de performanță ale VM-ului din cauza co-stop-ului ridicat, alegeți dimensiunea VM-ului conform recomandărilor producătorului software-ului care rulează pe acest VM și cu capabilitățile serverului fizic pe care rulează VM-ul.
Nu adăugați nuclee în rezervă; aceasta poate provoca probleme de performanță nu doar pentru VM-ul în sine, ci și pentru vecinii săi pe server.
Alte metrici utile CPU
Run – cât timp (ms) în perioada de măsurare vCPU a fost în stare RUN, adică efectiv a efectuat muncă utilă.
Idle – cât timp (ms) pe perioada de măsurare vCPU a fost în stare de inactivitate. Valorile mari Idle nu sunt o problemă, pur și simplu vCPU nu avea «ce să facă».
Wait – cât timp (ms) pe perioada de măsurare vCPU a fost în stare de așteptare. Deoarece în acest contor este inclus IDLE, valorile mari Wait nu indică neapărat o problemă. Dacă, însă, în condițiile unui Wait mare, IDLE este scăzut, înseamnă că VM a așteptat finalizarea operațiunilor de intrare/ieșire, ceea ce poate indica o problemă de performanță a hard disk-ului sau a unor dispozitive virtuale din VM.
Limită maximă – cât timp (ms) pe perioada de măsurare vCPU a fost în stare de pregătire din cauza unei limite impusă resurselor. Dacă performanța este inexplicabil de scăzută, este util să verifici valoarea acestui contor și limita de CPU în setările VM. VM poate avea limite stabilite de care nu știi. De exemplu, acest lucru se întâmplă atunci când VM a fost clonat dintr-un șablon pe care era impusă o limită de CPU.
Așteptare Swap – cât timp pe perioada de măsurare vCPU a așteptat operațiile cu Swap-ul VMkernel. Dacă valorile acestui contor sunt mai mari decât zero, atunci VM cu siguranță are probleme de performanță. Vom discuta mai în detaliu despre SWAP în articolul despre contoarele memoriei RAM.
ESXTOP
Dacă contorii de performanță din vCenter sunt buni pentru analiza datelor istorice, analiza operativă a problemelor este mai bine să fie efectuată în ESXTOP. Aici toate valorile sunt prezentate gata de utilizare (nu trebuie să le traduci), iar perioada minimă de măsurare este de 2 secunde.
Ecranul ESXTOP pentru CPU este accesat prin tasta „c” și arată astfel:
Pentru comoditate, poți păstra doar procesele mașinilor virtuale, apăsând Shift-V.
Pentru a vizualiza metricile pentru fiecare nucleu al VM-ului, apasă „e” și introdu GID-ul VM-ului de interes (30919 în captura de ecran de mai jos):
Voi trece rapid prin coloanele care sunt prezentate în mod implicit. Coloanele suplimentare pot fi adăugate apăsând „f”.
NWLD (Numărul de Lumi) – numărul de procese din grup. Pentru a extinde grupul și a vedea metricile pentru fiecare proces (de exemplu, pentru fiecare nucleu al unei VM multicore), apasă „e”. Dacă în grup sunt mai mult de un proces, valorile metricelor pentru grup sunt egale cu suma metricelor pentru procesele individuale.
%USED – câte cicli de CPU utilizează procesul sau grupul de procese.
%RUN – cât timp în perioada de măsurare procesul a fost în stare RUN, adică a efectuat muncă utilă. Se deosebește de %USED prin faptul că nu ia în considerare hyper-threading, scalarea frecvenței și timpul petrecut pe sarcini de sistem (%SYS).
%SYS – timpul petrecut pe sarcini de sistem, de exemplu: procesarea întreruperilor, input/output, activitatea rețelei etc. Valoarea poate fi mare dacă VM are un volum mare de input/output.
%OVRLP – cât timp un nucleu fizic, pe care se execută procesul VM, a fost utilizat pentru sarcini ale altor procese.
Aceste metrci secorelează între ele în felul următor:
%USED = %RUN + %SYS — %OVRLP.
De obicei, metrica %USED este mai informativă.
%WAIT – cât timp în perioada de măsurare procesul a fost în stare Wait. Include IDLE.
%IDLE – cât timp în perioada de măsurare procesul a fost în stare IDLE.
%SWPWT – cât timp în perioada de măsurare vCPU a așteptat operația cu VMkernel Swap.
%VMWAIT – cât timp în perioada de măsurare vCPU a fost în stare de așteptare a unui eveniment (de obicei input/output). Nu există un contor similar în vCenter. Valorile mari indică probleme cu input/output pe VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Dacă VM nu utilizează VMkernel Swap, atunci, în analiza problemelor de performanță, este util să se examineze %VMWAIT, deoarece această metrică nu ia în considerare timpul când VM nu a făcut nimic (%IDLE).
%RDY – cât timp în perioada de măsurare procesul a fost în stare Ready.
%CSTP – cât timp în perioada de măsurare procesul a fost în stare costop.
%MLMTD – cât timp în perioada de măsurare vCPU a fost în stare Ready din cauza unui limit stabilit pentru resurse.
%WAIT + %RDY + %CSTP + %RUN = 100% – nucleul VM este tot timpul în una dintre aceste patru stări.
CPU pe hypervizor
În vCenter există de asemenea contoare de performanță CPU pentru hypervizor, dar acestea nu prezintă un interes deosebit – sunt pur și simplu suma contoarelor pentru toate VM-urile de pe server.
Cel mai convenabil este să vizualizezi starea CPU pe server pe tab-ul Summary:
Pentru server, la fel ca și pentru mașina virtuală, există o alarmă standard:
În cazul unei încărcări ridicate a CPU-ului serverului, VM-urile care funcționează pe acesta încep să aibă probleme de performanță.
În ESXTOP, datele despre utilizarea CPU-ului serverului sunt prezentate în partea de sus a ecranului. Pe lângă încărcarea standard a CPU-ului, care este puțin informativă pentru hypervizori, există încă trei metrici:
UTILIZARE CORE(%) – utilizarea nucleului fizic al serverului. Acest contor arată cât timp, pe parcursul perioadei de măsurare, nucleul a efectuat muncă.
UTILIZARE PCPU(%) – dacă hyper-threading-ul este activat, fiecare nucleu fizic are două fire (PCPU). Această metrică arată cât timp fiecare fir a efectuat muncă.
PCPU UTILIZAT(%) – același lucru ca UTILIZARE PCPU(%), dar ia în considerare scalarea frecvenței (fie reducerea frecvenței nucleului pentru economisirea energiei, fie creșterea frecvenței nucleului prin tehnologia Turbo Boost) și hyper-threading.
PCPU_UTILIZAT% = UTILIZARE PCPU% * frecvența eficientă a nucleului / frecvența nominală a nucleului.
În această captură de ecran, pentru unele nuclee, din cauza funcționării Turbo Boost, valoarea UTILIZAT este mai mare de 100%, deoarece frecvența nucleului este mai mare decât cea nominală.
Câteva cuvinte despre modul în care este luat în considerare hyper-threading. Dacă procesele rulează 100% din timp pe ambele fire ale nucleului fizic al serverului, iar nucleul funcționează la frecvența nominală, atunci:
- UTILIZARE CORE pentru nucleu va fi 100%,
- UTILIZARE PCPU pentru ambele fire va fi 100%,
- PCPU UTILIZAT pentru ambele fire va fi 50%.
Dacă ambele fire nu au funcționat 100% din timp în perioada de măsurare, atunci în acele perioade în care firele au lucrat simultan, PCPU UTILIZAT pentru nuclee este împărțit la doi.
În ESXTOP există, de asemenea, un ecran cu parametrii de consum de energie pentru CPU-ul serverului. Aici se poate verifica dacă serverul utilizează tehnologiile de economisire a energiei: C-states și P-states. Se accesează cu tasta „p”:
Probleme standard de performanță a CPU-ului
În final, voi trece în revistă cauzele tipice ale problemelor de performanță a CPU-ului VM și voi oferi câteva sugestii scurte pentru rezolvarea acestora:
Frecvența nucleului este insuficientă. Dacă nu există posibilitatea de a muta VM pe nuclee mai performante, se poate încerca să se schimbe setările de consum de energie pentru ca Turbo Boost să funcționeze mai eficient.
Dimensionarea greșită a VM-ului (prea multe/prea puține nuclee). Dacă sunt puține nuclee, va fi o încărcare mare a CPU-ului VM. Dacă sunt prea multe, veți avea o co-stop mare.
O suprasubscriere mare a CPU-ului pe server. Dacă VM-ul are un Ready mare, reduceți suprasubscrierea CPU-ului.
Topologia NUMA greșită pe VMs mari. Topologia NUMA pe care o vede VM (vNUMA) trebuie să corespundă topologiei NUMA a serverului (pNUMA). Despre diagnosticare și posibile soluții pentru această problemă a fost scris, de exemplu, în cartea . Dacă nu doriți să vă aprofundați și nu aveți restricții de licență pentru sistemul de operare instalat pe VM, creați pe VM multe socketuri virtuale cu câte un nucleu. Nu veți pierde mult 🙂
Asta este tot despre CPU de la mine. Puneți întrebări. În partea următoare vă voi spune despre memoria RAM.
Linkuri utile
Sursa: habr.com
