Hvis du administrerer en virtuel infrastruktur baseret på VMware vSphere (eller en hvilken som helst anden teknologistack), hører du sandsynligvis ofte klager fra brugere: "Den virtuelle maskine er langsom!" I denne serie af artikler vil jeg analysere præstationsmålinger og fortælle dig, hvad og hvorfor det bliver langsommere, og hvordan du sikrer dig, at det ikke bliver langsommere.
Jeg vil overveje følgende aspekter af virtuelle maskiners ydeevne:
- CPU,
- VÆDDER,
- DISK,
- Netværk.
Jeg starter med CPU'en.
For at analysere ydeevne har vi brug for:
- vCenter ydeevnetællere – ydeevnetællere, hvis grafer kan ses gennem vSphere Client. Oplysninger om disse tællere er tilgængelige i enhver version af klienten (“tyk” klient i C#, webklient i Flex og webklient i HTML5). I disse artikler vil vi bruge skærmbilleder fra C#-klienten, kun fordi de ser bedre ud i miniature :)
- ESXTOP – et hjælpeprogram, der kører fra ESXi-kommandolinjen. Med dens hjælp kan du få værdierne af ydeevnetællere i realtid eller uploade disse værdier for en vis periode til en .csv-fil for yderligere analyse. Dernæst vil jeg fortælle dig mere om dette værktøj og give flere nyttige links til dokumentation og artikler om emnet.
Lidt teori
I ESXi er en separat proces – verden i VMware-terminologi – ansvarlig for driften af hver vCPU (virtuel maskinkerne). Der er også serviceprocesser, men ud fra et synspunkt om at analysere VM-ydeevne er de mindre interessante.
En proces i ESXi kan være i en af fire tilstande:
- Kør – processen udfører noget nyttigt arbejde.
- Vent – processen udfører ikke noget arbejde (tomgang) eller venter på input/output.
- Costop – en tilstand, der opstår i multi-core virtuelle maskiner. Det opstår, når hypervisor CPU-planlæggeren (ESXi CPU Scheduler) ikke kan planlægge den samtidige udførelse af alle aktive virtuelle maskine-kerner på de fysiske serverkerner. I den fysiske verden arbejder alle processorkerner parallelt, gæsteoperativsystemet inde i VM'en forventer lignende adfærd, så hypervisoren er nødt til at bremse VM-kernerne, der har evnen til at afslutte deres clock-cyklus hurtigere. I moderne versioner af ESXi bruger CPU-planlæggeren en mekanisme kaldet afslappet co-planlægning: hypervisoren overvejer kløften mellem den "hurtigste" og den "langsommeste" virtuelle maskine kerne (skæv). Hvis mellemrummet overstiger en vis tærskel, går den hurtige kerne ind i costop-tilstanden. Hvis VM-kerner bruger meget tid i denne tilstand, kan det forårsage problemer med ydeevnen.
- Ready – processen går ind i denne tilstand, når hypervisoren ikke er i stand til at allokere ressourcer til dens udførelse. Høje klarværdier kan forårsage VM-ydeevneproblemer.
Grundlæggende tællere for CPU-ydelse for virtuelle maskiner
CPU brug, %. Viser procentdelen af CPU-brug for en given periode.
Hvordan analyseres? Hvis en VM konsekvent bruger CPU på 90 %, eller der er peaks op til 100 %, så har vi problemer. Problemer kan ikke kun udtrykkes i den "langsomme" drift af applikationen inde i VM'en, men også i VM'ens utilgængelighed over netværket. Hvis overvågningssystemet viser, at VM'en med jævne mellemrum falder af, skal du være opmærksom på toppene i CPU-forbrugsgrafen.
Der er en standardalarm, der viser CPU-belastningen af den virtuelle maskine:
Hvad skal jeg gøre? Hvis en VM's CPU-brug konstant går gennem taget, så kan du overveje at øge antallet af vCPU'er (desværre hjælper dette ikke altid) eller flytte VM'en til en server med mere kraftfulde processorer.
CPU-brug i MHz
I graferne på vCenter Brug i % kan du kun se for hele den virtuelle maskine; der er ingen grafer for individuelle kerner (i Esctop er der % værdier for kerner). For hver kerne kan du se Usage i MHz.
Hvordan analyseres? Det sker, at en applikation ikke er optimeret til en multi-core arkitektur: den bruger kun én kerne 100%, og resten er inaktiv uden belastning. For eksempel, med standard sikkerhedskopieringsindstillinger starter MS SQL processen på kun én kerne. Som et resultat bliver sikkerhedskopieringen langsommere, ikke på grund af diskenes langsomme hastighed (det er, hvad brugeren oprindeligt klagede over), men fordi processoren ikke kan klare det. Problemet blev løst ved at ændre parametrene: backup begyndte at køre parallelt i flere filer (henholdsvis i flere processer).
Et eksempel på ujævn belastning på kerner.
Der er også en situation (som i grafen ovenfor), hvor kernerne belastes ujævnt, og nogle af dem har toppe på 100%. Som med kun at indlæse én kerne, vil alarmen for CPU-brug ikke virke (det er for hele VM), men der vil være problemer med ydeevnen.
Hvad skal jeg gøre? Hvis softwaren i en virtuel maskine indlæser kernerne ujævnt (bruger kun én kerne eller en del af kernerne), er der ingen mening i at øge antallet af dem. I dette tilfælde er det bedre at flytte VM'en til en server med mere kraftfulde processorer.
Du kan også prøve at tjekke strømforbrugsindstillingerne i serverens BIOS. Mange administratorer aktiverer High Performance-tilstand i BIOS og deaktiverer derved C-state og P-state energibesparende teknologier. Moderne Intel-processorer bruger Turbo Boost-teknologi, som øger frekvensen af individuelle processorkerner på bekostning af andre kerner. Men det virker kun, når energibesparende teknologier er slået til. Hvis vi deaktiverer dem, kan processoren ikke reducere strømforbruget for kerner, der ikke er indlæst.
VMware anbefaler ikke at deaktivere strømbesparende teknologier på servere, men at vælge tilstande, der så vidt muligt overlader strømstyringen til hypervisoren. I dette tilfælde skal du i hypervisorens strømforbrugsindstillinger vælge High Performance.
Hvis du har individuelle VM'er (eller VM-kerner) i din infrastruktur, der kræver øget CPU-frekvens, kan korrekt justering af strømforbruget forbedre deres ydeevne betydeligt.
CPU klar
Hvis VM-kernen (vCPU) er i tilstanden Klar, udfører den ikke nyttigt arbejde. Denne tilstand opstår, når hypervisoren ikke finder en ledig fysisk kerne, som den virtuelle maskines vCPU-proces kan tildeles.
Hvordan analyseres? Typisk, hvis en virtuel maskines kerner er i Klar-tilstand mere end 10 % af tiden, vil du bemærke ydeevneproblemer. Kort sagt, mere end 10 % af tiden venter VM'en på, at fysiske ressourcer bliver tilgængelige.
I vCenter kan du se 2 tællere relateret til CPU Ready:
- beredskab,
- Parat.
Værdierne for begge tællere kan ses både for hele VM'en og for individuelle kerner.
Readiness viser værdien med det samme som en procentdel, men kun i realtid (data for den sidste time, måleinterval 20 sekunder). Det er bedre kun at bruge denne tæller til at søge efter problemer "varmt i hælene".
Klare modværdier kan også ses fra et historisk perspektiv. Dette er nyttigt til at etablere mønstre og til en dybere analyse af problemet. For eksempel, hvis en virtuel maskine begynder at opleve ydeevneproblemer på et bestemt tidspunkt, kan du sammenligne intervallerne for CPU Ready-værdien med den samlede belastning på serveren, hvor denne VM kører, og træffe foranstaltninger for at reducere belastningen (hvis DRS fejler).
Klar, i modsætning til Readiness, vises ikke i procenter, men i millisekunder. Dette er en summeringstypetæller, det vil sige, den viser, hvor længe i løbet af måleperioden VM-kernen var i Klar-tilstand. Du kan konvertere denne værdi til en procentdel ved hjælp af en simpel formel:
(CPU klar summeringsværdi / (standard diagramopdateringsinterval i sekunder * 1000)) * 100 = CPU klar %
For eksempel, for VM'en i grafen nedenfor, vil den maksimale Ready-værdi for hele den virtuelle maskine være som følger:
Når du beregner Klar-procenten, skal du være opmærksom på to punkter:
- Ready-værdien for hele VM er summen af Ready på tværs af kerner.
- Måleinterval. For realtid er det 20 sekunder, og for eksempel på daglige diagrammer er det 300 sekunder.
Med aktiv fejlfinding kan disse simple punkter let gå glip af, og værdifuld tid kan spildes på at løse ikke-eksisterende problemer.
Lad os beregne Ready baseret på dataene fra grafen nedenfor. (324474/(20*1000))*100 = 1622% for hele VM. Hvis du ser på kernerne, er det ikke så skræmmende: 1622/64 = 25 % pr. kerne. I dette tilfælde er fangsten ret let at få øje på: Ready-værdien er urealistisk. Men hvis vi taler om 10-20% for hele VM'en med flere kerner, så kan værdien for hver kerne ligge inden for det normale område.
Hvad skal jeg gøre? En høj Ready-værdi angiver, at serveren ikke har nok processorressourcer til normal drift af virtuelle maskiner. I en sådan situation er der kun tilbage at reducere overabonnement fra processor (vCPU:pCPU). Dette kan naturligvis opnås ved at reducere parametrene for eksisterende VM'er eller ved at migrere en del af VM'erne til andre servere.
Co-stop
Hvordan analyseres? Denne tæller er også af typen Summation og konverteres til procenter på samme måde som Klar:
(CPU co-stop summeringsværdi / (standard diagramopdateringsinterval i sekunder * 1000)) * 100 = CPU co-stop %
Her skal du også være opmærksom på antallet af kerner på VM'en og måleintervallet.
I costop-tilstanden udfører kernen ikke nyttigt arbejde. Med det korrekte valg af VM-størrelse og normal belastning på serveren bør co-stop-tælleren være tæt på nul.
I dette tilfælde er belastningen klart unormal :)
Hvad skal jeg gøre? Hvis flere VM'er med et stort antal kerner kører på én hypervisor, og der er overabonnement på CPU'en, kan co-stop-tælleren stige, hvilket vil føre til problemer med ydeevnen af disse VM'er.
Co-stop vil også stige, hvis de aktive kerner i én VM bruger tråde på én fysisk serverkerne med hypertreading aktiveret. Denne situation kan for eksempel opstå, hvis VM'en har flere kerner end fysisk tilgængelig på serveren, hvor den kører, eller hvis "preferHT"-indstillingen er aktiveret for VM'en. Du kan læse om denne indstilling .
For at undgå problemer med VM-ydeevne på grund af høj co-stop skal du vælge VM-størrelsen i overensstemmelse med anbefalingerne fra producenten af softwaren, der kører på denne VM, og funktionerne på den fysiske server, hvor VM'en kører.
Tilføj ikke kerner i reserve; dette kan forårsage ydeevneproblemer ikke kun for VM'en selv, men også for dens naboer på serveren.
Andre nyttige CPU-metrics
Kør – hvor meget tid (ms) i løbet af måleperioden vCPU'en var i RUN-tilstand, det vil sige, at den rent faktisk udførte nyttigt arbejde.
tomgang – hvor længe (ms) i løbet af måleperioden vCPU'en var i en tilstand af inaktivitet. Høje tomgangsværdier er ikke et problem, vCPU'en havde bare "intet at gøre."
Vent – hvor længe (ms) i løbet af måleperioden vCPU'en var i ventetilstand. Da IDLE er inkluderet i denne tæller, indikerer høje venteværdier heller ikke et problem. Men hvis Wait IDLE er lav, når Wait er høj, betyder det, at VM'en ventede på, at I/O-handlinger skulle fuldføres, og dette kan igen indikere et problem med ydeevnen af harddisken eller virtuelle enheder i VM'en.
Max begrænset – hvor længe (ms) i løbet af måleperioden vCPU'en var i Klar-tilstand på grund af den indstillede ressourcegrænse. Hvis ydeevnen er uforklarligt lav, er det nyttigt at kontrollere værdien af denne tæller og CPU-grænsen i VM-indstillingerne. VM'er kan faktisk have grænser, som du ikke er klar over. For eksempel sker dette, når en VM blev klonet fra en skabelon, hvor CPU-grænsen var sat.
Byt vent – hvor længe i løbet af måleperioden, vCPU'en ventede på en operation med VMkernel Swap. Hvis værdierne af denne tæller er over nul, så har VM'en helt sikkert problemer med ydeevnen. Vi vil tale mere om SWAP i artiklen om RAM-tællere.
ESXTOP
Hvis ydeevnetællere i vCenter er gode til at analysere historiske data, så er operationel analyse af problemet bedre udført i ESXTOP. Her præsenteres alle værdier i færdiggjort form (ingen grund til at oversætte noget), og den mindste måleperiode er 2 sekunder.
ESXTOP-skærmen for CPU kaldes op med "c"-tasten og ser sådan ud:
For nemheds skyld kan du kun forlade virtuelle maskine-processer ved at trykke på Shift-V.
For at se metrics for individuelle VM-kerner, skal du trykke på "e" og indtaste GID'et for den VM af interesse (30919 i skærmbilledet nedenfor):
Lad mig kort gennemgå de kolonner, der præsenteres som standard. Yderligere kolonner kan tilføjes ved at trykke på "f".
NWLD (Antal verdener) – antal processer i gruppen. For at udvide gruppen og se metrics for hver proces (for eksempel for hver kerne i en multi-core VM), skal du trykke på "e". Hvis der er mere end én proces i en gruppe, så er de metriske værdier for gruppen lig med summen af metrikken for de enkelte processer.
%BRUGT – hvor mange server-CPU-cyklusser, der bruges af en proces eller gruppe af processer.
%LØB – hvor lang tid i løbet af måleperioden processen var i RUN-tilstand, dvs. udførte nyttigt arbejde. Den adskiller sig fra %USED ved, at den ikke tager højde for hyper-threading, frekvensskalering og tid brugt på systemopgaver (%SYS).
%SYS – tid brugt på systemopgaver, for eksempel: afbrydelsesbehandling, I/O, netværksdrift osv. Værdien kan være høj, hvis VM'en har en stor I/O.
%OVRLP – hvor meget tid den fysiske kerne, som VM-processen kører på, brugt på opgaver i andre processer.
Disse metrics relaterer sig til hinanden som følger:
%USED = %RUN + %SYS - %OVRLP.
Typisk er metrikken %USED mere informativ.
%VENTE – hvor lang tid i løbet af måleperioden processen var i ventetilstand. Aktiverer IDLE.
%LEDIG – hvor længe i løbet af måleperioden processen var i TOMGANG-tilstand.
%SWPWT – hvor længe i løbet af måleperioden, vCPU'en ventede på en operation med VMkernel Swap.
%VMWAIT – hvor længe i løbet af måleperioden vCPU'en var i tilstanden af at vente på en hændelse (normalt I/O). Der er ingen lignende tæller i vCenter. Høje værdier indikerer problemer med I/O på VM'en.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Hvis VM'en ikke bruger VMkernel Swap, er det tilrådeligt at se på %VMWAIT, når du analyserer ydeevneproblemer, da denne metrik ikke tager højde for det tidspunkt, hvor VM'en ikke gjorde noget (%IDLE).
%RDY – hvor længe i løbet af måleperioden processen var i Klar-tilstand.
%CSTP – hvor længe i løbet af måleperioden processen var i costop-tilstand.
%MLMTD – hvor længe i løbet af måleperioden vCPU'en var i Klar-tilstand på grund af den indstillede ressourcegrænse.
%WAIT + %RDY + %CSTP + %RUN = 100% – VM-kernen er altid i en af disse fire tilstande.
CPU på hypervisor
vCenter har også CPU-ydelsestællere til hypervisoren, men de er ikke noget interessante - de er simpelthen summen af tællerne for alle VM'er på serveren.
Den mest bekvemme måde at se CPU-status på serveren er på fanen Resume:
Til serveren såvel som til den virtuelle maskine er der en standardalarm:
Når serverens CPU-belastning er høj, begynder de VM'er, der kører på den, at opleve ydeevneproblemer.
I ESXTOP vises server-CPU-belastningsdata øverst på skærmen. Ud over standard CPU-belastningen, som ikke er særlig informativ for hypervisorer, er der yderligere tre målinger:
CORE UTIL(%) – indlæsning af den fysiske serverkerne. Denne tæller viser, hvor meget tid kernen udførte arbejde i løbet af måleperioden.
PCPU UTIL(%) – hvis hyper-threading er aktiveret, så er der to tråde (PCPU) pr. fysisk kerne. Denne metrik viser, hvor lang tid hver tråd tog at fuldføre arbejdet.
PCPU BRUGT (%) – det samme som PCPU UTIL(%), men tager højde for frekvensskalering (enten reduktion af kernefrekvensen til energibesparende formål eller forøgelse af kernefrekvensen på grund af Turbo Boost-teknologi) og hyper-threading.
PCPU_USED% = PCPU_UTIL% * effektiv kernefrekvens / nominel kernefrekvens.
I dette skærmbillede er USED-værdien for nogle kerner på grund af Turbo Boost større end 100 %, da kernefrekvensen er højere end den nominelle.
Et par ord om, hvordan hyper-threading tages i betragtning. Hvis processer udføres 100 % af tiden på begge tråde af serverens fysiske kerne, mens kernen fungerer ved den nominelle frekvens, så:
- CORE UTIL for kernen vil være 100 %,
- PCPU UTIL for begge tråde vil være 100 %,
- PCPU ANVENDT til begge tråde vil være 50 %.
Hvis begge tråde ikke virkede 100 % af tiden i måleperioden, i de perioder hvor trådene arbejdede parallelt, deles PCPU'en, der bruges til kernerne, i to.
ESXTOP har også en skærm med server CPU strømforbrug parametre. Her kan du se, om serveren bruger energibesparende teknologier: C-tilstande og P-tilstande. Kaldes af "p"-tasten:
Almindelige CPU-ydelsesproblemer
Til sidst vil jeg gennemgå de typiske årsager til problemer med VM CPU-ydeevne og give korte tips til at løse dem:
Kernehastigheden er ikke nok. Hvis det ikke er muligt at opgradere din VM til mere kraftfulde kerner, kan du prøve at ændre strømindstillingerne for at få Turbo Boost til at fungere mere effektivt.
Forkert VM-størrelse (for mange/få kerner). Hvis du installerer få kerner, vil der være en høj CPU-belastning på VM'en. Hvis der er meget, så tag et højt co-stop.
Stort overabonnement af CPU på serveren. Hvis VM'en har en høj Ready, skal du reducere CPU-overabonnementet.
Forkert NUMA-topologi på store VM'er. NUMA-topologien, der ses af VM'en (vNUMA), skal matche serverens NUMA-topologi (pNUMA). Diagnostik og mulige løsninger på dette problem står fx skrevet i bogen . Hvis du ikke vil gå dybere, og du ikke har licensbegrænsninger på operativsystemet installeret på VM'en, skal du lave mange virtuelle sockets på VM'en, en kerne ad gangen. Du vil ikke miste meget :)
Det er alt for mig om CPU'en. Stil spørgsmål. I den næste del vil jeg tale om RAM.
Nyttige links
Kilde: www.habr.com