Če upravljate virtualno infrastrukturo, ki temelji na VMware vSphere (ali katerem koli drugem tehnološkem skladu), verjetno pogosto slišite pritožbe uporabnikov: "Virtualni stroj je počasen!" V tej seriji člankov bom analiziral meritve uspešnosti in vam povedal, kaj in zakaj se upočasni in kako zagotoviti, da se ne upočasni.
Upošteval bom naslednje vidike delovanja virtualnega stroja:
- CPU
- OVEN,
- DISK,
- Omrežje.
Začel bom s procesorjem.
Za analizo uspešnosti potrebujemo:
- Števci zmogljivosti vCenter – števci zmogljivosti, katerih grafe si lahko ogledate prek odjemalca vSphere. Informacije o teh števcih so na voljo v kateri koli različici odjemalca (»debel« odjemalec v C#, spletni odjemalec v Flexu in spletni odjemalec v HTML5). V teh člankih bomo uporabili posnetke zaslona iz odjemalca C#, samo zato, ker izgledajo bolje v miniaturi :)
- ESXTOP – pripomoček, ki se zažene iz ukazne vrstice ESXi. Z njegovo pomočjo lahko dobite vrednosti števcev uspešnosti v realnem času ali naložite te vrednosti za določeno obdobje v datoteko .csv za nadaljnjo analizo. Nato vam bom povedal več o tem orodju in zagotovil več uporabnih povezav do dokumentacije in člankov na to temo.
Malo teorije
V ESXi je ločen proces – svet v terminologiji VMware – odgovoren za delovanje vsakega vCPU (jedro virtualnega stroja). Obstajajo tudi storitveni procesi, vendar so z vidika analize delovanja VM manj zanimivi.
Proces v ESXi je lahko v enem od štirih stanj:
- Run – postopek opravi koristno delo.
- Čakaj – proces ne opravlja nobenega dela (miruje) ali čaka na vhod/izhod.
- Costop – stanje, ki se pojavi v večjedrnih virtualnih strojih. Do tega pride, ko razporejevalnik CPE hipervizorja (ESXi CPU Scheduler) ne more načrtovati hkratnega izvajanja vseh aktivnih jeder navideznega stroja na jedrih fizičnega strežnika. V fizičnem svetu vsa procesorska jedra delujejo vzporedno, gostujoči OS znotraj VM pričakuje podobno vedenje, zato mora hipervizor upočasniti jedra VM, ki imajo možnost, da hitreje zaključijo svoj taktni cikel. V sodobnih različicah ESXi razporejevalnik procesorja uporablja mehanizem, imenovan sproščeno sorazporejanje: hipervizor upošteva vrzel med »najhitrejšim« in »najpočasnejšim« jedrom navideznega stroja (poševnost). Če vrzel preseže določen prag, hitro jedro preide v stanje costop. Če jedra VM preživijo veliko časa v tem stanju, lahko povzroči težave z zmogljivostjo.
- Želite – proces preide v to stanje, ko hipervizor ne more dodeliti sredstev za njegovo izvedbo. Visoke vrednosti pripravljenosti lahko povzročijo težave z zmogljivostjo VM.
Osnovni števci zmogljivosti procesorja virtualnega stroja
Poraba procesorja, %. Prikazuje odstotek uporabe procesorja za dano obdobje.
Kako analizirati? Če VM dosledno uporablja CPE pri 90 % ali so konice do 100 %, potem imamo težave. Težave se lahko izražajo ne le v “počasnem” delovanju aplikacije znotraj VM, temveč tudi v nedostopnosti VM preko omrežja. Če nadzorni sistem pokaže, da VM občasno odpade, bodite pozorni na vrhove v grafu porabe procesorja.
Obstaja standardni alarm, ki prikazuje obremenitev procesorja virtualnega stroja:
Kaj storiti? Če je poraba CPE-ja VM nenehno čez streho, potem lahko razmislite o povečanju števila vCPU-jev (žal to ne pomaga vedno) ali premaknitvi VM-ja na strežnik z zmogljivejšimi procesorji.
Poraba procesorja v MHz
V grafih na vCenter Usage v % lahko vidite le za celoten virtualni stroj; ni grafov za posamezna jedra (v Esxtopu so % vrednosti za jedra). Za vsako jedro lahko vidite porabo v MHz.
Kako analizirati? Zgodi se, da aplikacija ni optimizirana za večjedrno arhitekturo: uporablja samo eno jedro 100%, ostala pa mirujejo brez obremenitve. Na primer, s privzetimi nastavitvami varnostnega kopiranja MS SQL zažene postopek samo v enem jedru. Posledično se varnostno kopiranje upočasni ne zaradi počasne hitrosti diskov (nad tem se je uporabnik sprva pritoževal), temveč zato, ker procesor tega ne zmore. Težavo smo rešili s spremembo parametrov: varnostno kopiranje se je začelo izvajati vzporedno v več datotekah (oziroma v več procesih).
Primer neenakomerne obremenitve jeder.
Obstaja tudi situacija (kot na zgornjem grafu), ko so jedra neenakomerno obremenjena in imajo nekatera od njih vrhove 100%. Tako kot pri nalaganju samo enega jedra alarm za porabo procesorja ne bo deloval (velja za celoten VM), vendar bodo nastopile težave z delovanjem.
Kaj storiti? Če programska oprema v virtualnem stroju neenakomerno obremenjuje jedra (uporablja samo eno jedro ali del jeder), nima smisla povečevati njihovega števila. V tem primeru je bolje prestaviti VM na strežnik z zmogljivejšimi procesorji.
Prav tako lahko poskusite preveriti nastavitve porabe energije v BIOS-u strežnika. Mnogi skrbniki v BIOS-u omogočijo način visoke zmogljivosti in s tem onemogočijo tehnologije za varčevanje z energijo C-state in P-state. Sodobni procesorji Intel uporabljajo tehnologijo Turbo Boost, ki poveča frekvenco posameznih procesorskih jeder na račun drugih jeder. Vendar deluje le, če so vklopljene tehnologije za varčevanje z energijo. Če jih onemogočimo, procesor ne more zmanjšati porabe energije neobremenjenih jeder.
VMware priporoča, da na strežnikih ne onemogočite tehnologij za varčevanje z energijo, ampak da izberete načine, ki upravljanje porabe energije čim bolj prepuščajo hipervizorju. V tem primeru morate v nastavitvah porabe energije hipervizorja izbrati High Performance.
Če imate v svoji infrastrukturi posamezne VM (ali jedra VM), ki zahtevajo povečano frekvenco procesorja, lahko pravilno prilagajanje porabe energije znatno izboljša njihovo zmogljivost.
CPU pripravljen
Če je jedro VM (vCPU) v stanju pripravljenosti, ne opravlja koristnega dela. Ta pogoj se pojavi, ko hipervizor ne najde prostega fizičnega jedra, ki bi mu lahko dodelili proces vCPU virtualnega stroja.
Kako analizirati? Če so jedra navideznega stroja več kot 10 % časa v stanju pripravljenosti, boste običajno opazili težave z zmogljivostjo. Preprosto povedano, več kot 10 % časa VM čaka, da so fizični viri na voljo.
V vCenter si lahko ogledate 2 števca, povezana s CPU Ready:
- pripravljenost,
- Pripravljen.
Vrednosti obeh števcev si lahko ogledate tako za celoten VM kot za posamezna jedra.
Pripravljenost prikaže vrednost takoj v odstotkih, vendar le v realnem času (podatki za zadnjo uro, interval merjenja 20 sekund). Ta števec je bolje uporabiti samo za iskanje težav, ki so »za petami«.
Pripravljene vrednosti števca si lahko ogledate tudi z zgodovinskega vidika. To je uporabno za ugotavljanje vzorcev in za poglobljeno analizo problema. Na primer, če navidezni stroj ob določenem času začne doživljati težave z delovanjem, lahko primerjate intervale vrednosti CPE Ready s skupno obremenitvijo strežnika, kjer se izvaja ta VM, in sprejmete ukrepe za zmanjšanje obremenitve (če DRS ne uspe).
Pripravljenost, za razliko od pripravljenosti, ni prikazana v odstotkih, ampak v milisekundah. To je števec tipa Summation, kar pomeni, da prikazuje, koliko časa je bilo v obdobju merjenja jedro VM v stanju pripravljenosti. To vrednost lahko pretvorite v odstotke s preprosto formulo:
(Vrednost seštevka pripravljenosti CPE / (privzeti interval posodobitve grafikona v sekundah * 1000)) * 100 = % pripravljenosti CPE
Na primer, za VM na spodnjem grafu bo najvišja vrednost Ready za celoten virtualni stroj naslednja:
Pri izračunu odstotka pripravljenosti bodite pozorni na dve točki:
- Vrednost Ready za celoten VM je vsota Ready med jedri.
- Merilni interval. V realnem času je to 20 sekund, na primer na dnevnih lestvicah pa 300 sekund.
Z aktivnim odpravljanjem težav lahko te preproste točke zlahka spregledate in izgubite dragoceni čas za reševanje neobstoječih težav.
Izračunajmo Ready na podlagi podatkov iz spodnjega grafa. (324474/(20*1000))*100 = 1622 % za celoten VM. Če pogledate jedra, ni tako strašno: 1622/64 = 25 % na jedro. V tem primeru je ulov zelo lahko opaziti: vrednost Ready je nerealna. Če pa govorimo o 10–20 % za celoten VM z več jedri, potem je za vsako jedro lahko vrednost znotraj normalnega območja.
Kaj storiti? Visoka vrednost Ready pomeni, da strežnik nima dovolj procesorskih sredstev za normalno delovanje virtualnih strojev. V takšnih razmerah ostane le še zmanjšanje prevelike naročnine glede na procesor (vCPU:pCPU). Očitno je to mogoče doseči z zmanjšanjem parametrov obstoječih VM-jev ali s selitvijo dela VM-jev na druge strežnike.
Co-stop
Kako analizirati? Ta števec je prav tako tipa Summation in se pretvori v odstotke na enak način kot Ready:
(Vrednost vsote soustavitve CPE / (privzeti interval posodobitve grafikona v sekundah * 1000)) * 100 = % soustavitve CPE
Tukaj morate biti pozorni tudi na število jeder na VM in interval merjenja.
V stanju costop jedro ne opravlja koristnega dela. Ob pravilni izbiri velikosti VM in normalni obremenitvi strežnika mora biti števec co-stop blizu ničle.
V tem primeru je obremenitev očitno nenormalna :)
Kaj storiti? Če se na enem hipervizorju izvaja več navideznih strojev z velikim številom jeder in je na CPE prevelika naročnina, se lahko števec za zaustavitev poveča, kar bo povzročilo težave z delovanjem teh navideznih strojev.
Poleg tega se bo co-stop povečal, če aktivna jedra enega VM uporabljajo niti v enem fizičnem strežniškem jedru z omogočenim hiper-stopanjem. Do tega lahko pride na primer, če ima VM več jeder, kot je fizično na voljo na strežniku, kjer se izvaja, ali če je za VM omogočena nastavitev »preferHT«. O tej nastavitvi lahko preberete .
Da bi se izognili težavam z zmogljivostjo VM zaradi visokega co-stopa, izberite velikost VM v skladu s priporočili proizvajalca programske opreme, ki se izvaja na tem VM, in zmožnostmi fizičnega strežnika, kjer se VM izvaja.
Ne dodajajte jeder v rezervo; to lahko povzroči težave pri delovanju ne samo za sam VM, ampak tudi za njegove sosede na strežniku.
Druge uporabne meritve procesorja
Run – koliko časa (ms) med obdobjem merjenja je bil vCPE v stanju RUN, to je, da je dejansko opravljal koristno delo.
Mirovanje – kako dolgo (ms) med obdobjem merjenja je bil vCPU v stanju nedejavnosti. Visoke vrednosti nedejavnosti niso problem, vCPE preprosto ni imel »ničesar početi«.
Čakaj – kako dolgo (ms) med obdobjem merjenja je bil vCPU v stanju čakanja. Ker je IDLE vključen v ta števec, tudi visoke vrednosti čakanja ne pomenijo težave. Toda če je Wait IDLE nizek, medtem ko je Wait visok, to pomeni, da je VM čakal na dokončanje V/I operacij, to pa lahko pomeni težavo z delovanjem trdega diska ali katere koli virtualne naprave VM.
Max omejeno – kako dolgo (ms) med obdobjem merjenja je bil vCPU v stanju pripravljenosti zaradi nastavljene omejitve vira. Če je zmogljivost nerazložljivo nizka, je koristno preveriti vrednost tega števca in omejitev procesorja v nastavitvah VM. VM morda res imajo omejitve, ki se jih ne zavedate. To se na primer zgodi, ko je bil VM kloniran iz predloge, na kateri je bila nastavljena omejitev procesorja.
Zamenjaj počakajte – koliko časa je vCPE med obdobjem merjenja čakal na operacijo z VMkernel Swap. Če so vrednosti tega števca nad nič, potem ima VM zagotovo težave z zmogljivostjo. Več o SWAP bomo govorili v članku o števcih RAM.
ESXTOP
Če so števci uspešnosti v vCenter dobri za analizo zgodovinskih podatkov, potem je operativno analizo težave bolje narediti v ESXTOP. Tukaj so vse vrednosti predstavljene v pripravljeni obliki (ničesar ni treba prevajati), minimalno obdobje merjenja pa je 2 sekundi.
Zaslon ESXTOP za CPE se prikliče s tipko "c" in je videti takole:
Za udobje lahko pustite samo procese navideznega stroja s pritiskom na Shift-V.
Če si želite ogledati meritve za posamezna jedra VM, pritisnite »e« in vnesite GID VM, ki vas zanima (30919 na spodnjem posnetku zaslona):
Naj na kratko pregledam stolpce, ki so privzeto predstavljeni. Dodatne stolpce lahko dodate s pritiskom na "f".
NWLD (število svetov) – število procesov v skupini. Če želite razširiti skupino in si ogledati meritve za vsak proces (na primer za vsako jedro v večjedrnem VM), pritisnite »e«. Če je v skupini več kot en proces, so vrednosti metrike za skupino enake vsoti meritev za posamezne procese.
% UPORABLJENO – koliko ciklov procesorja strežnika uporablja proces ali skupina procesov.
%ZAŽENI – koliko časa je bil proces med obdobjem merjenja v stanju RUN, tj. opravil koristno delo. Od %USED se razlikuje po tem, da ne upošteva hiper-nitnosti, frekvenčnega skaliranja in časa, porabljenega za sistemske naloge (%SYS).
%SYS – čas, porabljen za sistemske naloge, na primer: obdelava prekinitev, V/I, delovanje omrežja itd. Vrednost je lahko visoka, če ima VM veliko V/I.
%OVRLP – koliko časa fizično jedro, na katerem teče proces VM, porabi za naloge drugih procesov.
Te meritve so med seboj povezane na naslednji način:
%USED = %RUN + %SYS - %OVRLP.
Običajno je metrika %USED bolj informativna.
% POČAKAJTE – koliko časa je bil proces med obdobjem merjenja v stanju čakanja. Omogoča IDLE.
%NEDEJAVEN – koliko časa je bil proces med obdobjem merjenja v stanju mirovanja.
%SWPWT – koliko časa je vCPU med obdobjem merjenja čakal na operacijo z VMkernel Swap.
%VMWAIT – kako dolgo je bil vCPU v obdobju čakanja na dogodek (običajno I/O). V vCenter ni podobnega števca. Visoke vrednosti kažejo na težave z V/I na VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Če VM ne uporablja VMkernel Swap, je pri analizi težav z zmogljivostjo priporočljivo pogledati %VMWAIT, saj ta metrika ne upošteva časa, ko VM ni delal ničesar (%IDLE).
%RDY – kako dolgo med obdobjem merjenja je bil proces v stanju pripravljenosti.
%CSTP – koliko časa je bil proces med obdobjem merjenja v stanju Costop.
%MLMTD – koliko časa je bil vCPE v obdobju merjenja v stanju pripravljenosti zaradi nastavljene omejitve virov.
%WAIT + %RDY + %CSTP + %RUN = 100 % – jedro VM je vedno v enem od teh štirih stanj.
CPU na hipervizorju
VCenter ima tudi števce zmogljivosti procesorja za hipervizor, vendar niso nič zanimivega - so preprosto vsota števcev za vse VM na strežniku.
Najprimernejši način za ogled stanja procesorja na strežniku je na zavihku Povzetek:
Za strežnik, kot tudi za virtualni stroj, obstaja standardni alarm:
Ko je obremenitev procesorja strežnika visoka, začnejo VM, ki se na njem izvajajo, doživljati težave z zmogljivostjo.
V ESXTOP so podatki o obremenitvi procesorja strežnika prikazani na vrhu zaslona. Poleg standardne obremenitve procesorja, ki za hipervizorje ni zelo informativna, obstajajo še tri meritve:
OSNOVNI UPORAB (%) – nalaganje fizičnega jedra strežnika. Ta števec prikazuje, koliko časa je jedro opravljalo delo v obdobju merjenja.
UPORABA PCPE (%) – če je hiper-nitnost omogočena, sta dve niti (PCPU) na fizično jedro. Ta metrika prikazuje, koliko časa je posamezna nit potrebovala za dokončanje dela.
UPORABLJEN PCPE (%) – enako kot PCPU UTIL(%), vendar upošteva skaliranje frekvence (bodisi zmanjšanje jedrne frekvence zaradi varčevanja z energijo bodisi povečanje jedrne frekvence zaradi tehnologije Turbo Boost) in hiper-nitnost.
PCPU_USED% = PCPU_UTIL% * efektivna jedrna frekvenca / nazivna jedrna frekvenca.
Na tem posnetku zaslona je za nekatera jedra zaradi Turbo Boost vrednost USED večja od 100 %, saj je frekvenca jedra višja od nominalne.
Nekaj besed o tem, kako se upošteva hipernitnost. Če se procesi izvajajo 100 % časa na obeh nitih fizičnega jedra strežnika, medtem ko jedro deluje z nominalno frekvenco, potem:
- CORE UTIL za jedro bo 100 %.
- PCPU UTIL za obe niti bo 100 %.
- UPORABA PCPE za obe niti bo 50 %.
Če obe niti med obdobjem merjenja nista delovali 100 % časa, potem se v tistih obdobjih, ko sta niti delovali vzporedno, PCPU, UPORABLJEN za jedra, razdeli na polovico.
ESXTOP ima tudi zaslon s parametri porabe energije procesorja strežnika. Tukaj lahko vidite, ali strežnik uporablja tehnologije za varčevanje z energijo: C-stanja in P-stanja. Priklican s tipko "p":
Pogoste težave z delovanjem procesorja
Nazadnje bom preučil tipične vzroke težav z delovanjem procesorja VM in podal kratke nasvete za njihovo odpravljanje:
Takt jedra ni dovolj. Če vašega virtualnega stroja ni mogoče nadgraditi na zmogljivejša jedra, lahko poskusite spremeniti nastavitve napajanja, da bo Turbo Boost deloval učinkoviteje.
Nepravilna velikost VM (preveč/malo jeder). Če namestite malo jeder, bo VM močno obremenjen CPE. Če je veliko, ujemite visok co-stop.
Velika prevelika naročnina na CPE na strežniku. Če ima VM visoko pripravljenost, zmanjšajte prekomerno naročnino na CPU.
Nepravilna topologija NUMA na velikih virtualnih strojih. Topologija NUMA, ki jo vidi VM (vNUMA), se mora ujemati s topologijo NUMA strežnika (pNUMA). Diagnostika in možne rešitve tega problema so zapisane na primer v knjigi . Če ne želite iti globlje in nimate licenčnih omejitev za OS, nameščen na VM, naredite veliko navideznih vtičnic na VM, eno jedro naenkrat. ne boste veliko izgubili :)
To je zame vse glede procesorja. Postavite vprašanja. V naslednjem delu bom govoril o RAM-u.
Uporabne povezave
Vir: www.habr.com