Hvis du administrerer en virtuell infrastruktur basert på VMware vSphere (eller en hvilken som helst annen teknologistabel), hører du sannsynligvis ofte klager fra brukere: "Den virtuelle maskinen er treg!" I denne serien med artikler vil jeg analysere ytelsesmålinger og fortelle deg hva og hvorfor den bremser ned og hvordan du kan sørge for at den ikke bremses.
Jeg vil vurdere følgende aspekter ved virtuell maskinytelse:
- CPU,
- RAM,
- DISK,
- Network.
Jeg starter med CPU.
For å analysere ytelsen trenger vi:
- vCenter ytelsestellere – ytelsestellere, hvis grafer kan sees gjennom vSphere Client. Informasjon om disse tellerne er tilgjengelig i alle versjoner av klienten (“tykk” klient i C#, webklient i Flex og webklient i HTML5). I disse artiklene vil vi bruke skjermbilder fra C#-klienten, bare fordi de ser bedre ut i miniatyr :)
- ESXTOP – et verktøy som kjører fra ESXi-kommandolinjen. Med dens hjelp kan du få verdiene til ytelsestellere i sanntid eller laste opp disse verdiene for en viss periode til en .csv-fil for videre analyse. Deretter skal jeg fortelle deg mer om dette verktøyet og gi flere nyttige lenker til dokumentasjon og artikler om emnet.
Litt teori
I ESXi er en egen prosess – verden i VMware-terminologi – ansvarlig for driften av hver vCPU (virtuell maskinkjerne). Det finnes også tjenesteprosesser, men med tanke på å analysere VM-ytelse er de mindre interessante.
En prosess i ESXi kan være i en av fire tilstander:
- Kjør – prosessen utfører noe nyttig arbeid.
- Vent – prosessen fungerer ikke (inaktiv) eller venter på input/output.
- Costop – en tilstand som oppstår i multi-core virtuelle maskiner. Det oppstår når hypervisor-CPU-planleggeren (ESXi CPU Scheduler) ikke kan planlegge samtidig kjøring av alle aktive virtuelle maskinkjerner på de fysiske serverkjernene. I den fysiske verden fungerer alle prosessorkjerner parallelt, gjeste-OS inne i VM forventer lignende oppførsel, så hypervisoren må bremse VM-kjernene som har muligheten til å fullføre klokkesyklusen raskere. I moderne versjoner av ESXi bruker CPU-planleggeren en mekanisme som kalles avslappet co-planlegging: hypervisoren vurderer gapet mellom den "raskeste" og den "tregeste" virtuelle maskinkjernen (skjevhet). Hvis gapet overstiger en viss terskel, går den raske kjernen inn i costop-tilstanden. Hvis VM-kjerner bruker mye tid i denne tilstanden, kan det forårsake ytelsesproblemer.
- Klar – prosessen går inn i denne tilstanden når hypervisoren ikke er i stand til å allokere ressurser for utførelse. Høye klarverdier kan forårsake problemer med VM-ytelse.
Grunnleggende CPU-ytelsestelere for virtuell maskin
CPU bruk, %. Viser prosentandelen av CPU-bruk for en gitt periode.
Hvordan analysere? Hvis en VM konsekvent bruker CPU på 90 % eller det er topper på opptil 100 %, så har vi problemer. Problemer kan uttrykkes ikke bare i den "langsomme" driften av applikasjonen inne i VM, men også i utilgjengelighet til VM over nettverket. Hvis overvåkingssystemet viser at VM med jevne mellomrom faller av, vær oppmerksom på toppene i CPU-bruk-grafen.
Det er en standard alarm som viser CPU-belastningen til den virtuelle maskinen:
Hva gjør jeg? Hvis en VMs CPU-bruk hele tiden går gjennom taket, kan du tenke på å øke antall vCPUer (dessverre hjelper ikke dette alltid) eller flytte VM-en til en server med kraftigere prosessorer.
CPU-bruk i MHz
I grafene på vCenter-bruk i % kan du bare se for hele den virtuelle maskinen; det er ingen grafer for individuelle kjerner (i Esxtop er det %-verdier for kjerner). For hver kjerne kan du se Bruk i MHz.
Hvordan analysere? Det hender at en applikasjon ikke er optimalisert for en flerkjernearkitektur: den bruker bare en kjerne 100%, og resten er inaktiv uten belastning. For eksempel, med standard sikkerhetskopieringsinnstillinger, starter MS SQL prosessen på bare én kjerne. Som et resultat avtar sikkerhetskopieringen ikke på grunn av den langsomme hastigheten til diskene (dette er hva brukeren først klaget på), men fordi prosessoren ikke kan takle det. Problemet ble løst ved å endre parameterne: sikkerhetskopiering begynte å kjøre parallelt i flere filer (henholdsvis i flere prosesser).
Et eksempel på ujevn belastning på kjerner.
Det er også en situasjon (som i grafen over) når kjernene belastes ujevnt og noen av dem har topper på 100 %. Som med å laste bare én kjerne, vil ikke alarmen for CPU-bruk fungere (den er for hele VM), men det vil være ytelsesproblemer.
Hva gjør jeg? Hvis programvaren i en virtuell maskin laster kjernene ujevnt (bruker kun én kjerne eller deler av kjernene), er det ingen vits i å øke antallet. I dette tilfellet er det bedre å flytte VM-en til en server med kraftigere prosessorer.
Du kan også prøve å sjekke strømforbruksinnstillingene i server-BIOS. Mange administratorer aktiverer høyytelsesmodus i BIOS og deaktiverer dermed energisparende teknologier for C-tilstander og P-tilstander. Moderne Intel-prosessorer bruker Turbo Boost-teknologi, som øker frekvensen av individuelle prosessorkjerner på bekostning av andre kjerner. Men det fungerer bare når energisparende teknologier er slått på. Hvis vi deaktiverer dem, kan ikke prosessoren redusere strømforbruket til kjerner som ikke er lastet.
VMware anbefaler ikke å deaktivere strømsparende teknologier på servere, men å velge moduser som overlater strømstyring til hypervisoren så mye som mulig. I dette tilfellet, i hypervisorens strømforbruksinnstillinger, må du velge Høy ytelse.
Hvis du har individuelle VM-er (eller VM-kjerner) i infrastrukturen din som krever økt CPU-frekvens, kan riktig justering av strømforbruket forbedre ytelsen betydelig.
CPU klar
Hvis VM-kjernen (vCPU) er i Klar-tilstand, utfører den ikke nyttig arbeid. Denne tilstanden oppstår når hypervisoren ikke finner en ledig fysisk kjerne som den virtuelle maskinens vCPU-prosess kan tilordnes.
Hvordan analysere? Vanligvis, hvis en virtuell maskins kjerner er i Klar-tilstand mer enn 10 % av tiden, vil du legge merke til ytelsesproblemer. Enkelt sagt, mer enn 10 % av tiden venter VM på at fysiske ressurser blir tilgjengelige.
I vCenter kan du se 2 tellere relatert til CPU Ready:
- beredskap,
- Klar.
Verdiene til begge tellerne kan sees både for hele VM og for individuelle kjerner.
Beredskap viser verdien umiddelbart i prosent, men kun i sanntid (data for siste time, måleintervall 20 sekunder). Det er bedre å bruke denne telleren bare for å søke etter problemer "varmt på hælene".
Klare motverdier kan også sees fra et historisk perspektiv. Dette er nyttig for å etablere mønstre og for dypere analyse av problemet. For eksempel, hvis en virtuell maskin begynner å oppleve ytelsesproblemer på et bestemt tidspunkt, kan du sammenligne intervallene til CPU Ready-verdien med den totale belastningen på serveren der denne VM-en kjører, og iverksette tiltak for å redusere belastningen (hvis DRS mislykkes).
Klar, i motsetning til Readiness, vises ikke i prosenter, men i millisekunder. Dette er en teller av typen Summation, det vil si at den viser hvor lenge i løpet av måleperioden VM-kjernen var i Klar-tilstand. Du kan konvertere denne verdien til en prosentandel ved å bruke en enkel formel:
(CPU klar summeringsverdi / (standard diagramoppdateringsintervall i sekunder * 1000)) * 100 = CPU klar %
For eksempel, for VM i grafen nedenfor, vil topp Ready-verdien for hele den virtuelle maskinen være som følger:
Når du beregner Klar-prosenten, bør du være oppmerksom på to punkter:
- Ready-verdien for hele VM er summen av Ready på tvers av kjerner.
- Måleintervall. For sanntid er det 20 sekunder, og for eksempel på daglige diagrammer er det 300 sekunder.
Med aktiv feilsøking kan disse enkle punktene lett gå glipp av og verdifull tid kan kastes bort på å løse ikke-eksisterende problemer.
La oss beregne Ready basert på dataene fra grafen nedenfor. (324474/(20*1000))*100 = 1622 % for hele VM. Hvis du ser på kjernene er det ikke så skummelt: 1622/64 = 25 % per kjerne. I dette tilfellet er fangsten ganske lett å få øye på: Ready-verdien er urealistisk. Men hvis vi snakker om 10–20 % for hele VM med flere kjerner, kan verdien for hver kjerne være innenfor normalområdet.
Hva gjør jeg? En høy Ready-verdi indikerer at serveren ikke har nok prosessorressurser for normal drift av virtuelle maskiner. I en slik situasjon gjenstår det bare å redusere overabonnement av prosessor (vCPU:pCPU). Dette kan åpenbart oppnås ved å redusere parametrene til eksisterende VM-er eller ved å migrere deler av VM-ene til andre servere.
Co-stop
Hvordan analysere? Denne telleren er også av typen Summasjon og konverteres til prosenter på samme måte som Klar:
(CPU co-stop summering verdi / (diagram standard oppdateringsintervall i sekunder * 1000)) * 100 = CPU co-stop %
Her må du også ta hensyn til antall kjerner på VM og måleintervallet.
I costop-tilstanden utfører ikke kjernen nyttig arbeid. Med riktig valg av VM-størrelse og normal belastning på serveren, bør co-stop-telleren være nær null.
I dette tilfellet er belastningen helt klart unormal :)
Hva gjør jeg? Hvis flere VM-er med et stort antall kjerner kjører på én hypervisor og det er overabonnement på CPU-en, kan co-stop-telleren øke, noe som vil føre til problemer med ytelsen til disse VM-ene.
Co-stop vil også øke hvis de aktive kjernene til én VM bruker tråder på én fysisk serverkjerne med hypertreading aktivert. Denne situasjonen kan for eksempel oppstå hvis VM-en har flere kjerner enn det som er fysisk tilgjengelig på serveren der den kjører, eller hvis "preferHT"-innstillingen er aktivert for VM-en. Du kan lese om denne innstillingen .
For å unngå problemer med VM-ytelsen på grunn av høy co-stop, velg VM-størrelsen i samsvar med anbefalingene fra produsenten av programvaren som kjører på denne VM-en og egenskapene til den fysiske serveren der VM-en kjører.
Ikke legg til kjerner i reserve; dette kan føre til ytelsesproblemer ikke bare for VM selv, men også for naboene på serveren.
Andre nyttige CPU-målinger
Kjør – hvor mye tid (ms) i løpet av måleperioden vCPU var i RUN-tilstand, det vil si at den faktisk utførte nyttig arbeid.
Idle – hvor lenge (ms) i løpet av måleperioden vCPU var i en tilstand av inaktivitet. Høye tomgangsverdier er ikke et problem, vCPU-en hadde bare "ingenting å gjøre."
Vent – hvor lenge (ms) i løpet av måleperioden vCPU var i ventetilstand. Siden IDLE er inkludert i denne telleren, indikerer høye venteverdier heller ikke noe problem. Men hvis Wait IDLE er lav når Wait er høy, betyr det at VM ventet på at I/O-operasjoner skulle fullføres, og dette kan igjen indikere et problem med ytelsen til harddisken eller eventuelle virtuelle enheter til VM.
Maks begrenset – hvor lenge (ms) i løpet av måleperioden vCPU var i Klar-tilstand på grunn av den angitte ressursgrensen. Hvis ytelsen er uforklarlig lav, er det nyttig å sjekke verdien til denne telleren og CPU-grensen i VM-innstillingene. VM-er kan faktisk ha begrensninger som du ikke er klar over. Dette skjer for eksempel når en VM ble klonet fra en mal som CPU-grensen ble satt på.
Bytt vent – hvor lenge i løpet av måleperioden ventet vCPU på en operasjon med VMkernel Swap. Hvis verdiene til denne telleren er over null, har VM definitivt ytelsesproblemer. Vi snakker mer om SWAP i artikkelen om RAM-tellere.
ESXTOP
Hvis ytelsetellere i vCenter er gode for å analysere historiske data, er operasjonell analyse av problemet bedre gjort i ESXTOP. Her presenteres alle verdier i ferdig form (ingen grunn til å oversette noe), og minimum måleperiode er 2 sekunder.
ESXTOP-skjermen for CPU kalles opp med "c"-tasten og ser slik ut:
For enkelhets skyld kan du bare la virtuelle maskinprosesser stå ved å trykke Shift-V.
For å se beregninger for individuelle VM-kjerner, trykk "e" og skriv inn GID-en til VM-en du er interessert i (30919 i skjermbildet nedenfor):
La meg kort gå gjennom kolonnene som er presentert som standard. Ytterligere kolonner kan legges til ved å trykke "f".
NWLD (Antall verdener) – antall prosesser i gruppen. For å utvide gruppen og se beregninger for hver prosess (for eksempel for hver kjerne i en multi-core VM), trykk "e". Hvis det er mer enn én prosess i en gruppe, er de metriske verdiene for gruppen lik summen av metrikkene for de individuelle prosessene.
%BRUKTE – hvor mange server-CPU-sykluser som brukes av en prosess eller gruppe prosesser.
%LØPE – hvor lenge i løpet av måleperioden prosessen var i RUN-tilstand, dvs. gjorde nyttig arbeid. Den skiller seg fra %USED ved at den ikke tar hensyn til hyper-threading, frekvensskalering og tid brukt på systemoppgaver (%SYS).
%SYS – tid brukt på systemoppgaver, for eksempel: avbruddsbehandling, I/O, nettverksdrift osv. Verdien kan være høy hvis VM har en stor I/O.
%OVRLP – hvor mye tid den fysiske kjernen som VM-prosessen kjører på brukte på oppgaver i andre prosesser.
Disse beregningene er relatert til hverandre som følger:
%USED = %RUN + %SYS - %OVRLP.
Vanligvis er %USED-beregningen mer informativ.
%VENTE – hvor lenge i løpet av måleperioden prosessen var i ventetilstand. Aktiverer IDLE.
%TOMGANG – hvor lenge i løpet av måleperioden prosessen var i IDLE-tilstand.
%SWPWT – hvor lenge i løpet av måleperioden ventet vCPU på en operasjon med VMkernel Swap.
%VMWAIT – hvor lenge i løpet av måleperioden vCPU var i tilstanden til å vente på en hendelse (vanligvis I/O). Det er ingen lignende teller i vCenter. Høye verdier indikerer problemer med I/O på VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Hvis VM-en ikke bruker VMkernel Swap, er det tilrådelig å se på %VMWAIT når du analyserer ytelsesproblemer, siden denne beregningen ikke tar hensyn til tidspunktet da VM-en ikke gjorde noe (%IDLE).
%RDY – hvor lenge i løpet av måleperioden prosessen var i Klar-tilstand.
%CSTP – hvor lenge i løpet av måleperioden prosessen var i costop-tilstand.
%MLMTD – hvor lenge i løpet av måleperioden vCPU var i Klar-tilstand på grunn av den angitte ressursgrensen.
%WAIT + %RDY + %CSTP + %RUN = 100% – VM-kjernen er alltid i en av disse fire tilstandene.
CPU på hypervisor
vCenter har også CPU-ytelsestellere for hypervisoren, men de er ikke noe interessant - de er ganske enkelt summen av tellerne for alle VM-er på serveren.
Den mest praktiske måten å se CPU-statusen på serveren på er på Sammendrag-fanen:
For serveren, så vel som for den virtuelle maskinen, er det en standard alarm:
Når serverens CPU-belastning er høy, begynner VM-ene som kjører på den å oppleve ytelsesproblemer.
I ESXTOP presenteres server CPU-belastningsdata øverst på skjermen. I tillegg til standard CPU-belastning, som ikke er veldig informativ for hypervisorer, er det ytterligere tre beregninger:
KJERNEUTIL(%) – lasting av den fysiske serverkjernen. Denne telleren viser hvor mye tid kjernen utførte arbeid i løpet av måleperioden.
PCPU UTIL(%) – hvis hyper-threading er aktivert, er det to tråder (PCPU) per fysisk kjerne. Denne beregningen viser hvor lang tid det tok for hver tråd å fullføre arbeidet.
PCPU BRUKT(%) – det samme som PCPU UTIL(%), men tar hensyn til frekvensskalering (enten reduserer kjernefrekvensen for energisparingsformål, eller øker kjernefrekvensen på grunn av Turbo Boost-teknologi) og hypertråding.
PCPU_USED% = PCPU_UTIL% * effektiv kjernefrekvens / nominell kjernefrekvens.
I dette skjermbildet, for noen kjerner, på grunn av Turbo Boost, er USED-verdien større enn 100 %, siden kjernefrekvensen er høyere enn den nominelle.
Noen få ord om hvordan hyper-threading er tatt i betraktning. Hvis prosesser utføres 100 % av tiden på begge trådene i serverens fysiske kjerne, mens kjernen opererer med den nominelle frekvensen, så:
- CORE UTIL for kjernen vil være 100 %,
- PCPU UTIL for begge trådene vil være 100 %,
- PCPU BRUKT for begge trådene vil være 50 %.
Hvis begge trådene ikke fungerte 100 % av tiden i løpet av måleperioden, i de periodene hvor trådene fungerte parallelt, er PCPUEN BRUKT for kjernene delt i to.
ESXTOP har også en skjerm med server CPU strømforbruk parametere. Her kan du se om serveren bruker energisparende teknologier: C-tilstander og P-tilstander. Kalt opp med "p"-tasten:
Vanlige problemer med CPU-ytelse
Til slutt vil jeg gå over de typiske årsakene til problemer med VM CPU-ytelse og gi korte tips for å løse dem:
Kjerneklokkehastigheten er ikke nok. Hvis det ikke er mulig å oppgradere VM-en til kraftigere kjerner, kan du prøve å endre strøminnstillingene for å få Turbo Boost til å fungere mer effektivt.
Feil VM-størrelse (for mange/få kjerner). Hvis du installerer få kjerner, vil det være høy CPU-belastning på VM. Hvis det er mye, ta en høy co-stop.
Stort overabonnement av CPU på serveren. Hvis VM har en høy Ready, reduser CPU-overabonnement.
Feil NUMA-topologi på store VM-er. NUMA-topologien sett av VM (vNUMA) må samsvare med NUMA-topologien til serveren (pNUMA). Diagnostikk og mulige løsninger på dette problemet står for eksempel skrevet i boken . Hvis du ikke vil gå dypere og du ikke har lisensieringsbegrensninger på operativsystemet installert på VM-en, lag mange virtuelle sockets på VM-en, en kjerne om gangen. Du vil ikke tape mye :)
Det er alt for meg om CPU. Stille spørsmål. I neste del skal jeg snakke om RAM.
Nyttige lenker
Kilde: www.habr.com