As jo in firtuele ynfrastruktuer beheare basearre op VMware vSphere (of in oare technologystack), dan hearre jo wierskynlik faaks klachten fan brûkers: "De firtuele masine is stadich!". Yn dizze searje artikels sil ik prestaasjesmetriken analysearje en jo fertelle wat en wêrom "fertraagt" en hoe't jo kinne soargje dat it net "fertraagt".
Ik sil de folgjende aspekten fan prestaasjes fan firtuele masines beskôgje:
- cpu,
- KEZYN,
- skiif,
- Netwurk.
Ik sil begjinne mei de CPU.
Foar prestaasjesanalyse hawwe wy nedich:
- vCenter Performance Counters - prestaasjestellers, wêrfan grafiken kinne wurde besjoen fia de vSphere Client. Ynformaasje oer dizze tellers is beskikber yn elke ferzje fan 'e kliïnt ("dikke" client yn C #, web client yn Flex, en web client yn HTML5). Yn dizze artikels sille wy skermôfbyldings brûke fan 'e C#-kliïnt, gewoan om't se better útsjen yn miniatuer :)
- ESXTOP is in helpmiddel dat rint fan de ESXi kommando rigel. Mei har help kinne jo de wearden fan prestaasjestellers yn realtime krije of dizze wearden foar in bepaalde perioade uploade nei in .csv-bestân foar fierdere analyze. Folgjende sil ik jo mear fertelle oer dit ark en wat nuttige keppelings leverje nei dokumintaasje en artikels oer it ûnderwerp.
In bytsje teory
Yn ESXi is in apart proses ferantwurdlik foar de wurking fan elke vCPU (firtuele masine kernel) - wrâld yn VMware terminology. D'r binne ek tsjinstprosessen, mar út it eachpunt fan VM-prestaasjesanalyse binne se minder ynteressant.
In proses yn ESXi kin wêze yn ien fan fjouwer steaten:
- run It proses docht wat nuttich wurk.
- Wachtsje - it proses docht gjin wurk (idle) of wachtet op ynfier / útfier.
- Costop - in steat dy't foarkomt yn multi-core firtuele masines. It bart as de hypervisor syn CPU planner (ESXi CPU Scheduler) kin net planne alle aktive firtuele masine kearnen te rinnen op de tsjinner syn fysike kearnen tagelyk. Yn 'e fysike wrâld rinne alle prosessor-kearnen parallel, it gast-OS binnen de VM ferwachtet ferlykber gedrach, sadat de hypervisor de VM-kearnen fertrage moat, dy't de kâns hawwe om de syklus flugger te foltôgjen. Yn moderne ferzjes fan ESXi brûkt de CPU scheduler in meganisme neamd ûntspannen co-scheduling: de hypervisor berekkent it gat tusken de "rapste" en "stadichste" firtuele masine kearn (skew). As it gat boppe in bepaalde drompel komt, komt de "snelle" kearn de kostensteat yn. As de VM-kearnen in protte tiid yn dizze steat besteegje, kin it prestaasjesproblemen feroarsaakje.
- klear - it proses komt yn dizze steat as de hypervisor net by steat is om middels te allocearjen foar syn útfiering. Hege kleare wearden kinne VM-prestaasjesproblemen feroarsaakje.
Main VM CPU prestaasjes counters
CPU-gebrûk, %. Toant it persintaazje CPU-gebrûk foar de opjûne perioade.
Hoe analysearje? As de VM de CPU konsekwint brûkt op 90% of d'r binne peaks oant 100%, dan hawwe wy in probleem. Problemen kinne net allinich útdrukt wurde yn 'e "stadige" wurking fan' e applikaasje yn 'e VM, mar ek yn' e ûnberikberens fan 'e VM oer it netwurk. As it tafersjochsysteem lit sjen dat de VM periodyk falt, jouwe dan omtinken oan de peaks op 'e CPU-gebrûkgrafyk.
D'r is in standert Alarm dat de CPU-lading fan 'e firtuele masine toant:
Wat moat ik dwaan? As de VM hieltyd CPU-gebrûk hat fan skaal ôf, dan kinne jo tinke oan it fergrutsjen fan it oantal vCPU's (spitigernôch helpt dit net altyd) of it ferpleatsen fan de VM nei in tsjinner mei effisjintere processors.
CPU-gebrûk yn Mhz
Yn 'e grafiken op vCenter kin Gebrûk yn% allinich wurde besjoen foar de heule firtuele masine, d'r binne gjin grafiken foar yndividuele kearnen (yn Esxtop binne d'r wearden yn% foar kearnen). Foar elke kearn kinne jo gebrûk sjen yn MHz.
Hoe analysearje? It bart dat in applikaasje net optimalisearre is foar in multi-core arsjitektuer: it brûkt mar ien kearn op 100%, en de rest is idle sûnder lading. Bygelyks, mei standert reservekopy ynstellings, MS SQL begjint it proses op mar ien kearn. As gefolch, backup fertraget net fanwege de stadige snelheid fan de skiven (dit is wat de brûker earstoan klage oer), mar omdat de prosessor kin net omgean. It probleem waard oplost troch it feroarjen fan de parameters: reservekopy begon parallel te rinnen yn ferskate bestannen (respektivelik yn ferskate prosessen).
In foarbyld fan unjildich laden fan kearnen.
D'r is ek in situaasje (lykas yn 'e grafyk hjirboppe) as de kearnen unjildich laden wurde en guon fan har peaks hawwe fan 100%. Lykas by it laden fan mar ien kearn, sil it CPU Usage-alarm net wurkje (it is oer de VM), mar d'r sille prestaasjesproblemen wêze.
Wat moat ik dwaan? As de software yn 'e firtuele masine de kearnen unjildich laadt (brûkt mar ien kearn as in diel fan' e kearnen), makket it gjin sin om har oantal te fergrutsjen. Yn dit gefal is it better om de VM te ferpleatsen nei in server mei effisjintere processors.
Jo kinne ek besykje te kontrolearjen de macht ynstellings yn de tsjinner syn BIOS. In protte behearders skeakelje de High Performance-modus yn 'e BIOS yn en skeakelje dêrmei de C-staten en P-staten enerzjybesparjende technologyen út. Moderne Intel-processors brûke Turbo Boost-technology, dy't de frekwinsje fan yndividuele prosessorkearnen fergruttet op kosten fan oare kearnen. Mar it wurket allinich as enerzjybesparjende technologyen binne ynskeakele. As wy se útskeakelje, dan kin de prosessor it enerzjyferbrûk fan net laden kearnen net ferminderje.
VMware riedt oan om enerzjybesparjende technologyen op servers net út te skeakeljen, mar modi te kiezen dy't maksimale enerzjybehear jouwe oan 'e hypervisor. Tagelyk moatte jo yn 'e hypervisor-ynstellingen foar enerzjyferbrûk selektearje High Performance.
As jo yndividuele VM's (as VM-kearnen) hawwe yn jo ynfrastruktuer dy't in ferhege CPU-frekwinsje fereaskje, kin it goed konfigurearjen fan enerzjyferbrûk har prestaasjes signifikant ferbetterje.
CPU Ready
As de VM-kearn (vCPU) yn 'e Ready-status is, docht it net brûkber wurk. Dizze tastân komt foar as de hypervisor gjin frije fysike kearn fynt dêr't it vCPU-proses fan 'e firtuele masine kin wurde tawiisd.
Hoe analysearje? Typysk, as de kearnen fan in firtuele masine mear as 10% fan 'e tiid yn' e Ready-status binne, dan sille jo prestaasjesproblemen fernimme. Simply set, mear dan 10% fan 'e tiid wachtet de VM op' e beskikberens fan fysike boarnen.
Yn vCenter kinne jo 2 tellers sjen relatearre oan CPU Ready:
- reewilligens,
- Klear.
De wearden fan beide tellers kinne wurde besjoen sawol foar de heule VM as foar yndividuele kearnen.
Readiness toant de wearde fuortendaliks as in persintaazje, mar allinnich yn Real-time (gegevens foar de lêste oere, mjitting ynterval 20 sekonden). Dizze teller wurdt it bêste allinich brûkt om problemen te finen yn 'e heule efterfolging.
Reade tellerwearden kinne ek wurde besjoen yn in histoarysk perspektyf. Dit is nuttich foar it fêststellen fan patroanen en foar djipper analyse fan it probleem. Bygelyks, as in VM begjint te hawwen prestaasjes problemen op in bepaalde tiid, kinne jo ferlykje de CPU Ready hovering yntervallen mei de totale lading op de tsjinner dêr't de VM rint en nimme stappen te ferminderjen de lading (as DRS mislearre).
Ready, oars as Readiness, wurdt net yn persintaazjes werjûn, mar yn millisekonden. Dit is in teller fan it type Summation, dat is, it lit sjen hoefolle tiid yn 'e mjitperioade de VM-kearn yn' e Ready-status wie. Jo kinne dizze wearde konvertearje nei in persintaazje mei in ienfâldige formule:
(CPU klear summaasjewearde / (standert bywurkingsynterval foar diagram yn sekonden * 1000)) * 100 = CPU klear %
Bygelyks, foar de VM yn 'e grafyk hjirûnder soe de peak Ready-wearde foar de heule firtuele masine wêze:
By it berekkenjen fan de Ready-wearde as persintaazje, moatte jo omtinken jaan oan twa punten:
- De Ready-wearde oer de heule VM is de som fan Ready oer kearnen.
- Mjitting ynterval. Foar Real-time is dit 20 sekonden, en bygelyks op deistige charts is dit 300 sekonden.
Mei aktive problemen sjitten kinne dizze ienfâldige mominten maklik wurde mist en weardefolle tiid fergriemd wurde by it oplossen fan net-besteand problemen.
Litte wy Ready berekkenje op basis fan de gegevens út 'e grafyk hjirûnder. (324474/(20*1000))*100 = 1622% foar de hiele VM. As jo nei de kearnen sjogge, is it net sa eng: 1622/64 = 25% per kearn. Yn dit gefal is it fangen frij maklik te spotten: de Ready-wearde is net realistysk. Mar as wy it oer 10-20% prate foar de folsleine VM mei ferskate kearnen, dan kin de wearde foar elke kearn binnen it normale berik wêze.
Wat moat ik dwaan? In hege Ready wearde jout oan dat de tsjinner hat net genôch prosessor middels foar de normale wurking fan firtuele masines. Yn sa'n situaasje bliuwt it allinich om de oerabonnemint te ferminderjen troch prosessor (vCPU: pCPU). Fansels kin dit berikt wurde troch de parameters fan besteande VM's te ferminderjen of troch in diel fan 'e VM te migrearjen nei oare servers.
Co-stop
Hoe analysearje? Dizze teller hat ek it Summation-type en wurdt omsetten nei persintaazjes op deselde wize as Ready:
(CPU co-stop summaasjewearde / (standert bywurkingsynterval foar diagram yn sekonden * 1000)) * 100 = CPU co-stop %
Hjir moatte jo ek omtinken jaan oan it oantal kearnen per VM en it mjitynterval.
Yn 'e costop-steat docht de kernel gjin nuttich wurk. Mei juste VM-sizing en normale serverbelêsting moat de co-stop-teller tichtby nul wêze.
Yn dit gefal is de lading dúdlik abnormaal :)
Wat moat ik dwaan? As ferskate VM's mei in grut oantal kearnen op deselde hypervisor rinne en der is in oerabonnemint troch CPU, dan kin de co-stop-teller tanimme, wat sil liede ta problemen mei de prestaasjes fan dizze VM's.
Ek sil co-stop tanimme as threads wurde brûkt foar aktive kearnen fan ien VM op ien fysike serverkearn mei hypertreading ynskeakele. Dizze situaasje kin bygelyks foarkomme as de VM mear kearnen hat dan it fysyk hat op 'e tsjinner wêr't it rint, of as de "foarkarHT" ynstelling is ynskeakele foar de VM. Jo kinne lêze oer dizze ynstelling. .
Om VM-prestaasjesproblemen te foarkommen fanwege hege ko-stops, grutte de VM neffens de oanbefellings fan de fabrikant foar de software dy't rint op dy VM en de mooglikheden fan 'e fysike tsjinner wêr't de VM rint.
Foegje gjin kearnen ta yn reserve, dit kin prestaasjesproblemen net allinich foar de VM sels feroarsaakje, mar ek foar syn buorlju op 'e tsjinner.
Oare nuttige CPU-metriken
run - hoe lang (ms) yn 'e mjittingsperioade de vCPU yn' e RUN-status wie, dat is, it hat eins brûkber wurk dien.
idle - hoefolle tiid (ms) yn 'e mjitperioade wie de vCPU yn' e idle steat. Hege Idle-wearden binne gjin probleem, it is gewoan dat de vCPU "neat te dwaan" hie.
Wachtsje - hoe lang (ms) yn 'e mjitperioade wie de vCPU yn' e Wachtstân. Sûnt IDLE is opnaam yn dizze teller, jouwe hege Wachtwearden ek gjin probleem oan. Mar as Wait IDLE leech is as heech, dan wachte de VM op it foltôgjen fan I / O-operaasjes, en dit kin op syn beurt in probleem oanjaan mei de prestaasjes fan 'e hurde skiif of alle firtuele apparaten fan' e VM.
Max beheind - hoe lang (ms) yn 'e mjitperioade wie de vCPU yn' e Ready-status fanwege de ynstelde boarnelimyt. As de prestaasjes ûnferklearber leech binne, dan is it handich om de wearde fan dizze teller en de CPU-limyt te kontrolearjen yn 'e VM-ynstellingen. VM's kinne yndie limiten hawwe wêrfan jo net witte. Bygelyks, dit bart as in VM waard cloned út in sjabloan dat hie in CPU limyt ynsteld op it.
Swap wachtsje - hoe lang yn 'e mjitperioade de vCPU wachte op in operaasje mei VMkernel Swap. As de wearde fan dizze teller boppe nul is, dan hat de VM perfoarst prestaasjesproblemen. Wy sille mear prate oer SWAP yn it artikel oer RAM-tellers.
ESXTOP
As de prestaasjestellers yn vCenter goed binne foar it analysearjen fan histoaryske gegevens, dan is online analyze fan it probleem better dien yn ESXTOP. Hjir wurde alle wearden presintearre yn ôfmakke foarm (net nedich om neat te oersetten), en de minimale mjitperioade is 2 sekonden.
It ESXTOP-skerm op 'e CPU wurdt oproppen mei de "c"-kaai en sjocht der sa út:
Foar gemak kinne jo allinich de prosessen fan 'e firtuele masine ferlitte troch op Shift-V te drukken.
Om metriken foar yndividuele VM-kearnen te besjen, druk op "e" en typ de GID yn fan 'e VM wêryn jo ynteressearre binne (30919 yn 'e skermôfbylding hjirûnder):
Ik gean koart troch de kolommen dy't standert wurde presintearre. Oanfoljende kolommen kinne tafoege wurde troch te drukken op "f".
NWLD (oantal wrâlden) is it oantal prosessen yn 'e groep. Om de groep út te wreidzjen en metriken te sjen foar elk proses (bygelyks foar elke kearn fan in multi-core VM), druk op "e". As d'r mear as ien proses yn in groep is, dan binne de metriken foar de groep gelyk oan de som fan de metriken foar de yndividuele prosessen.
%GEBRUKTE - hoefolle server CPU-syklusen in proses of groep prosessen brûkt.
% RUN - hoe lang yn 'e mjitperioade it proses wie yn' e RUN-status, d.w.s. die nuttich wurk. Ferskil fan %USED yn dat it gjin rekken hâldt mei hyper-threading, frekwinsjeskalearring en tiid bestege oan systeemtaken (%SYS).
%SYS - tiid bestege oan systeemtaken, bygelyks: ûnderbrekkingsferwurking, I / O, netwurking, ensfh. De wearde kin heech wêze as de VM in protte I / O hat.
%OVRLP - hoefolle tiid de fysike kearn wêrop it VM-proses rint bestege oan taken fan oare prosessen.
Dizze metriken relatearje as folgjend oan elkoar:
%USED = %RUN + %SYS - %OVRLP.
Gewoanlik is de %USED metryske mear ynformative.
%WACHTSJE - hoe lang yn 'e mjitperioade it proses yn' e Wachtstân wie. Omfettet IDLE.
%IDLE - hoe lang yn 'e mjitperioade it proses yn' e IDLE-status wie.
%SWPWT - hoe lang yn 'e mjitperioade de vCPU wachte op in operaasje mei VMkernel Swap.
%VMWAIT - hoefolle tiid yn 'e mjitperioade de vCPU wie yn' e steat fan wachtsjen op in evenemint (meastentiids I / O). Der is gjin ferlykbere teller yn vCenter. Hege wearden jouwe problemen oan mei I / O op 'e VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
As de VM gjin VMkernel Swap brûkt, dan is it by it analysearjen fan prestaasjesproblemen oan te rieden om te sjen nei % VMWAIT, om't dizze metrik gjin rekken hâldt mei de tiid dat de VM neat dien hat (% IDLE).
%RDY - hoe lang yn 'e mjitperioade it proses yn' e Reade steat wie.
%CSTP - hoe lang yn 'e mjitperioade it proses yn' e steat fan stop wie.
%MLMTD - hoe lang yn 'e mjitperioade de vCPU yn' e Reade-status wie fanwegen de ynstelde boarnelimyt.
%WAIT + %RDY + %CSTP + %RUN = 100% - de VM-kearn is altyd yn ien fan dizze fjouwer steaten.
CPU op hypervisor
vCenter hat ek CPU-prestaasjestellers foar de hypervisor, mar se binne neat nijsgjirrich - it is gewoan de som fan 'e tellers foar alle VM's op 'e tsjinner.
De maklikste manier om de steat fan 'e CPU op' e tsjinner te besjen is op it ljepblêd Gearfetting:
Foar de tsjinner, lykas foar de firtuele masine, is d'r in standert Alarm:
As de lading op 'e server CPU heech is, begjinne de VM's dy't derop rinne, prestaasjesproblemen te ûnderfinen.
Yn ESXTOP, server CPU load gegevens wurdt presintearre oan de boppekant fan it skerm. Neist de standert CPU-lading, dy't net heul ynformatyf is foar hypervisors, binne d'r noch trije metriken:
CORE UTIL(%) - laden fan 'e kearn fan' e fysike tsjinner. Dizze teller lit sjen hoefolle tiid de kearn wurk dien hat yn 'e mjitperioade.
PCPU UTIL(%) - as hyper-threading ynskeakele is, dan binne d'r twa threaden (PCPU) per fysike kearn. Dizze metrik lit sjen hoe lang elke tried wurk hat dien.
PCPU GEBRUK (%) - itselde as PCPU UTIL (%), mar nimt rekken mei frekwinsje skaalfergrutting (of it ferleegjen fan de kearnfrekwinsje om macht te besparjen, of it fergrutsjen fan de kearnfrekwinsje troch Turbo Boost technology) en hyper-threading.
PCPU_USED% = PCPU_UTIL% * effektive kearnklok / nominale kearnklok.
Yn dit skermôfbylding is foar guon kearnen, fanwege Turbo Boost, de USED-wearde grutter dan 100%, om't de kearnfrekwinsje heger is as de nominale.
In pear wurden oer hoe't hyper-threading wurdt rekken holden. As prosessen 100% fan 'e tiid wurde útfierd op beide triedden fan' e fysike kearn fan 'e tsjinner, wylst de kearn rint op' e nominale frekwinsje, dan:
- CORE UTIL foar kearn sil 100% wêze,
- PCPU UTIL foar beide diskusjes sil 100% wêze,
- PCPU GEBRUK foar beide triedden sil 50% wêze.
As beide triedden net 100% fan 'e tiid wurken yn' e mjittingsperioade, dan yn dy perioaden dat de triedden parallel wurken, wurdt de PCPU GEBRUIKT foar de kearnen halve.
ESXTOP hat ek in skerm mei server CPU power ynstellings. Hjir kinne jo sjen oft de tsjinner brûkt enerzjybesparjende technologyen: C-staten en P-staten. Oanroppen troch de "p" kaai:
Algemiene problemen mei CPU-prestaasjes
Uteinlik gean ik oer de typyske oarsaken fan problemen mei VM CPU-prestaasjes en jou koarte tips foar it oplossen fan se:
Net genôch kearn klok. As it net mooglik is om de VM te upgrade nei machtiger kearnen, kinne jo besykje de krêftynstellingen te feroarjen sadat Turbo Boost effisjinter wurket.
Ferkearde VM-sizing (tefolle / pear kearnen). As jo in pear kearnen pleatse, sil d'r in hege lading wêze op 'e CPU fan' e VM. As in protte, fange in hege co-stop.
Grutte CPU-oerabonnemint op 'e tsjinner. As de VM heech Ready is, ferleegje de CPU-oerabonnemint.
Ferkearde NUMA-topology op grutte VM's. De NUMA-topology sjoen troch de VM (vNUMA) moat oerienkomme mei de NUMA-topology (pNUMA) fan de tsjinner. Oer de diagnoaze en mooglike oplossingen foar dit probleem stiet bygelyks yn it boek . As jo net djip wolle gean en jo gjin lisinsjebeperkingen hawwe op it OS ynstalleare op 'e VM, meitsje dan in protte firtuele sockets op' e VM foar ien kearn. Jo sille net ferlieze folle 🙂
Dat is alles oer de CPU foar my. Stel fragen. Yn it folgjende diel sil ik prate oer RAM.
Nuttige keppelings
Boarne: www.habr.com