Om du administrerar en virtuell infrastruktur baserad på VMware vSphere (eller någon annan teknikstack), hör du förmodligen ofta klagomål från användare: "Den virtuella maskinen är långsam!" I den här serien av artiklar kommer jag att analysera prestandamått och berätta vad och varför det saktar ner och hur man ser till att det inte saktar ner.
Jag kommer att överväga följande aspekter av virtuell maskinprestanda:
- CPU,
- BAGGE,
- DISK,
- Nätverk.
Jag börjar med CPU.
För att analysera prestanda behöver vi:
- vCenter prestandaräknare – prestandaräknare, vars grafer kan ses via vSphere Client. Information om dessa räknare finns tillgänglig i alla versioner av klienten (”tjock” klient i C#, webbklient i Flex och webbklient i HTML5). I dessa artiklar kommer vi att använda skärmdumpar från C#-klienten, bara för att de ser bättre ut i miniatyr :)
- ESXTOP – ett verktyg som körs från ESXi-kommandoraden. Med dess hjälp kan du få värdena för prestandaräknare i realtid eller ladda upp dessa värden under en viss period till en .csv-fil för vidare analys. Därefter ska jag berätta mer om det här verktyget och tillhandahålla flera användbara länkar till dokumentation och artiklar om ämnet.
Lite teori
I ESXi är en separat process – värld i VMware-terminologi – ansvarig för driften av varje vCPU (virtuell maskinkärna). Det finns också tjänsteprocesser, men ur synvinkeln att analysera VM-prestanda är de mindre intressanta.
En process i ESXi kan vara i ett av fyra tillstånd:
- Körning – processen utför en del nyttigt arbete.
- Vänta – processen gör inget arbete (tomgång) eller väntar på input/output.
- Costop – ett tillstånd som uppstår i virtuella maskiner med flera kärnor. Det inträffar när hypervisorns CPU-schemaläggare (ESXi CPU Scheduler) inte kan schemalägga den samtidiga exekveringen av alla aktiva virtuella maskinkärnor på de fysiska serverkärnorna. I den fysiska världen arbetar alla processorkärnor parallellt, gästoperativsystemet inuti den virtuella datorn förväntar sig liknande beteende, så hypervisorn måste sakta ner de virtuella processorkärnorna som har förmågan att avsluta sin klockcykel snabbare. I moderna versioner av ESXi använder CPU-schemaläggaren en mekanism som kallas relaxed co-scheduling: hypervisorn tar hänsyn till gapet mellan den "snabbaste" och den "långsammaste" virtuella maskinkärnan (skew). Om gapet överstiger en viss tröskel går den snabba kärnan in i costop-tillståndet. Om VM-kärnor tillbringar mycket tid i detta tillstånd kan det orsaka prestandaproblem.
- Klar – processen går in i detta tillstånd när hypervisorn inte kan allokera resurser för dess exekvering. Höga redo-värden kan orsaka problem med VM-prestanda.
Grundläggande CPU-prestandaräknare för virtuell maskin
CPU-användning, %. Visar procentandelen av CPU-användning för en given period.
Hur analyserar man? Om en virtuell dator konsekvent använder CPU på 90 % eller det finns toppar på upp till 100 %, så har vi problem. Problem kan uttryckas inte bara i den "långsamma" driften av applikationen inuti den virtuella datorn, utan också i den virtuella datorns otillgänglighet över nätverket. Om övervakningssystemet visar att den virtuella datorn periodvis faller av, var uppmärksam på topparna i CPU-användningsdiagrammet.
Det finns ett standardlarm som visar CPU-belastningen på den virtuella maskinen:
Vad ska man göra? Om en virtuell dators CPU-användning ständigt går igenom taket, kan du tänka på att öka antalet vCPU:er (tyvärr hjälper det inte alltid) eller flytta den virtuella datorn till en server med kraftfullare processorer.
CPU-användning i MHz
I graferna på vCenter Användning i % kan du bara se för hela den virtuella maskinen; det finns inga grafer för enskilda kärnor (i Esxtop finns %-värden för kärnor). För varje kärna kan du se Användning i MHz.
Hur analyserar man? Det händer att en applikation inte är optimerad för en flerkärnig arkitektur: den använder bara en kärna till 100%, och resten är inaktiva utan belastning. Till exempel, med standardinställningar för säkerhetskopiering, startar MS SQL processen på endast en kärna. Som ett resultat saktar säkerhetskopieringen ner inte på grund av hårddiskarnas långsamma hastighet (detta är vad användaren från början klagade på), utan på grund av att processorn inte klarar det. Problemet löstes genom att ändra parametrarna: säkerhetskopiering började köras parallellt i flera filer (i flera processer).
Ett exempel på ojämn belastning på kärnor.
Det finns också en situation (som i grafen ovan) när kärnorna belastas ojämnt och några av dem har toppar på 100 %. Som med att bara ladda en kärna kommer larmet för CPU-användning inte att fungera (det är för hela virtuella datorn), men det kommer att uppstå prestandaproblem.
Vad ska man göra? Om programvaran i en virtuell maskin laddar kärnorna ojämnt (använder bara en kärna eller en del av kärnorna) är det ingen idé att öka antalet. I det här fallet är det bättre att flytta den virtuella datorn till en server med kraftfullare processorer.
Du kan också prova att kontrollera strömförbrukningsinställningarna i serverns BIOS. Många administratörer aktiverar högpresterande läge i BIOS och inaktiverar därigenom energisparande tekniker för C-tillstånd och P-tillstånd. Moderna Intel-processorer använder Turbo Boost-teknik, vilket ökar frekvensen av enskilda processorkärnor på bekostnad av andra kärnor. Men det fungerar bara när energibesparande teknik är påslagen. Om vi inaktiverar dem kan processorn inte minska strömförbrukningen för kärnor som inte är laddade.
VMware rekommenderar att man inte inaktiverar energibesparande teknik på servrar, utan man väljer lägen som överlåter energihanteringen till hypervisorn så mycket som möjligt. I det här fallet, i hypervisorns strömförbrukningsinställningar, måste du välja High Performance.
Om du har individuella virtuella datorer (eller VM-kärnor) i din infrastruktur som kräver ökad CPU-frekvens, kan korrekt justering av strömförbrukningen förbättra deras prestanda avsevärt.
CPU redo
Om VM-kärnan (vCPU) är i läget Klar utför den inte användbart arbete. Detta tillstånd uppstår när hypervisorn inte hittar en ledig fysisk kärna till vilken den virtuella maskinens vCPU-process kan tilldelas.
Hur analyserar man? Vanligtvis, om en virtuell maskins kärnor är i Klar-tillståndet mer än 10 % av tiden, kommer du att märka prestandaproblem. Enkelt uttryckt, mer än 10 % av tiden väntar den virtuella datorn på att fysiska resurser blir tillgängliga.
I vCenter kan du se 2 räknare relaterade till CPU Ready:
- beredskap,
- Redo.
Värdena för båda räknarna kan ses både för hela VM och för enskilda kärnor.
Readiness visar värdet omedelbart i procent, men endast i realtid (data för den senaste timmen, mätintervall 20 sekunder). Det är bättre att använda den här disken bara för att söka efter problem "varma på hälarna".
Redo motvärden kan också ses ur ett historiskt perspektiv. Detta är användbart för att etablera mönster och för djupare analys av problemet. Till exempel, om en virtuell maskin börjar uppleva prestandaproblem vid en viss tidpunkt, kan du jämföra intervallen för CPU Ready-värdet med den totala belastningen på servern där denna virtuella dator körs, och vidta åtgärder för att minska belastningen (om DRS misslyckas).
Klar, till skillnad från Readiness, visas inte i procent, utan i millisekunder. Detta är en räknare av typen Summation, det vill säga den visar hur länge under mätperioden VM-kärnan var i Ready-läge. Du kan omvandla detta värde till en procentsats med en enkel formel:
(CPU redo summeringsvärde / (diagrammets standarduppdateringsintervall i sekunder * 1000)) * 100 = CPU redo %
Till exempel, för den virtuella datorn i diagrammet nedan, kommer toppvärdet för Ready för hela den virtuella maskinen att vara som följer:
När du beräknar redo-procenten bör du vara uppmärksam på två punkter:
- Ready-värdet för hela den virtuella datorn är summan av Ready över kärnor.
- Mätintervall. För realtid är det 20 sekunder, och till exempel på dagliga diagram är det 300 sekunder.
Med aktiv felsökning kan dessa enkla punkter lätt missas och värdefull tid kan slösas bort på att lösa obefintliga problem.
Låt oss beräkna Ready baserat på data från grafen nedan. (324474/(20*1000))*100 = 1622% för hela den virtuella datorn. Om du tittar på kärnorna är det inte så läskigt: 1622/64 = 25 % per kärna. I det här fallet är fångsten ganska lätt att upptäcka: Ready-värdet är orealistiskt. Men om vi pratar om 10–20 % för hela VM:n med flera kärnor, så kan värdet för varje kärna ligga inom det normala intervallet.
Vad ska man göra? Ett högt Ready-värde indikerar att servern inte har tillräckligt med processorresurser för normal drift av virtuella maskiner. I en sådan situation återstår bara att minska överabonnemang av processor (vCPU:pCPU). Uppenbarligen kan detta uppnås genom att minska parametrarna för befintliga virtuella datorer eller genom att migrera delar av virtuella datorer till andra servrar.
Co-stop
Hur analyserar man? Denna räknare är också av typen Summation och omvandlas till procentsatser på samma sätt som Ready:
(CPU co-stop summeringsvärde / (diagrammets standarduppdateringsintervall i sekunder * 1000)) * 100 = CPU co-stop %
Här måste du också vara uppmärksam på antalet kärnor på VM:n och mätintervallet.
I costop-tillståndet utför kärnan inte användbart arbete. Med rätt val av VM-storlek och normal belastning på servern bör co-stop-räknaren vara nära noll.
I det här fallet är belastningen helt klart onormal :)
Vad ska man göra? Om flera virtuella datorer med ett stort antal kärnor körs på en hypervisor och det finns överabonnemang på processorn, kan co-stop-räknaren öka, vilket kommer att leda till problem med prestandan för dessa virtuella datorer.
Co-stop kommer också att öka om de aktiva kärnorna i en virtuell dator använder trådar på en fysisk serverkärna med hypertreading aktiverat. Den här situationen kan till exempel uppstå om den virtuella datorn har fler kärnor än fysiskt tillgängliga på servern där den körs, eller om inställningen "preferHT" är aktiverad för den virtuella datorn. Du kan läsa om denna inställning .
För att undvika problem med den virtuella datorns prestanda på grund av högt co-stop, välj den virtuella datorns storlek i enlighet med rekommendationerna från tillverkaren av programvaran som körs på denna virtuella dator och funktionerna hos den fysiska server där den virtuella datorn körs.
Lägg inte till kärnor i reserv, detta kan orsaka prestandaproblem inte bara för själva VM:n utan även för dess grannar på servern.
Andra användbara CPU-mått
Körning – hur mycket tid (ms) under mätperioden som vCPU:n var i RUN-läge, det vill säga att den faktiskt utförde användbart arbete.
Idle – hur länge (ms) under mätperioden vCPU:n var i ett tillstånd av inaktivitet. Höga tomgångsvärden är inte ett problem, vCPU:n hade bara "inget att göra."
Vänta – hur länge (ms) under mätperioden vCPU:n var i väntat läge. Eftersom IDLE ingår i denna räknare indikerar inte heller höga väntevärden något problem. Men om Wait IDLE är låg när Wait är hög betyder det att den virtuella datorn väntade på att I/O-operationer skulle slutföras, och detta kan i sin tur indikera ett problem med hårddiskens prestanda eller virtuella enheter i den virtuella datorn.
Max begränsat – hur länge (ms) under mätperioden vCPU:n var i Ready-läge på grund av den inställda resursgränsen. Om prestandan är oförklarligt låg är det användbart att kontrollera värdet på denna räknare och CPU-gränsen i VM-inställningarna. VM:er kan verkligen ha gränser som du inte är medveten om. Detta händer till exempel när en virtuell dator klonades från en mall på vilken CPU-gränsen sattes.
Byt vänta – hur länge under mätperioden vCPU:n väntade på en operation med VMkernel Swap. Om värdena för denna räknare är över noll, har den virtuella datorn definitivt prestandaproblem. Vi kommer att prata mer om SWAP i artikeln om RAM-räknare.
ESXTOP
Om prestandaräknare i vCenter är bra för att analysera historiska data, görs operationsanalys av problemet bättre i ESXTOP. Här presenteras alla värden i färdig form (du behöver inte översätta något), och den minsta mätperioden är 2 sekunder.
ESXTOP-skärmen för CPU tas fram med "c"-tangenten och ser ut så här:
För enkelhetens skull kan du bara lämna virtuella maskinprocesser genom att trycka på Shift-V.
För att se mätvärden för individuella VM-kärnor, tryck på "e" och ange GID för den virtuella datorn av intresse (30919 i skärmdumpen nedan):
Låt mig kort gå igenom kolumnerna som presenteras som standard. Ytterligare kolumner kan läggas till genom att trycka på "f".
NWLD (Antal världar) – antal processer i gruppen. För att utöka gruppen och se mätvärden för varje process (till exempel för varje kärna i en multi-core virtuell dator), tryck på "e". Om det finns mer än en process i en grupp, är de metriska värdena för gruppen lika med summan av måtten för de individuella processerna.
%BEGAGNADE – hur många server-CPU-cykler som används av en process eller grupp av processer.
%SPRINGA – hur länge under mätperioden processen var i RUN-läge, d.v.s. gjorde nyttigt arbete. Den skiljer sig från %USED genom att den inte tar hänsyn till hypertrådning, frekvensskalning och tid som spenderas på systemuppgifter (%SYS).
%SYS – tid som läggs på systemuppgifter, till exempel: avbrottsbearbetning, I/O, nätverksdrift etc. Värdet kan vara högt om den virtuella datorn har en stor I/O.
%OVRLP – hur mycket tid den fysiska kärnan som VM-processen körs på ägnas åt uppgifter i andra processer.
Dessa mätvärden relaterar till varandra enligt följande:
%USED = %RUN + %SYS - %OVRLP.
Vanligtvis är måttet %USED mer informativt.
%VÄNTA – hur länge under mätperioden processen var i Vänteläge. Aktiverar IDLE.
%PÅ TOMGÅNG – hur länge under mätperioden processen var i IDLE-läge.
%SWPWT – hur länge under mätperioden vCPU:n väntade på en operation med VMkernel Swap.
%VMWAIT – hur länge under mätperioden vCPU:n väntade på en händelse (vanligtvis I/O). Det finns ingen liknande räknare i vCenter. Höga värden indikerar problem med I/O på den virtuella datorn.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Om den virtuella datorn inte använder VMkernel Swap, är det lämpligt att titta på %VMWAIT vid analys av prestandaproblem, eftersom detta mått inte tar hänsyn till tiden då den virtuella datorn inte gjorde något (%IDLE).
%RDY – hur länge under mätperioden processen var i läge Klar.
%CSTP – hur länge under mätperioden processen var i kostnadsläge.
%MLMTD – hur länge under mätperioden vCPU:n var i Ready-läge på grund av den inställda resursgränsen.
%WAIT + %RDY + %CSTP + %RUN = 100% – VM-kärnan är alltid i ett av dessa fyra tillstånd.
CPU på hypervisor
vCenter har också CPU-prestandaräknare för hypervisorn, men de är inget intressanta – de är helt enkelt summan av räknarna för alla virtuella datorer på servern.
Det bekvämaste sättet att se CPU-status på servern är på fliken Sammanfattning:
För servern, såväl som för den virtuella maskinen, finns det ett standardlarm:
När serverns CPU-belastning är hög börjar de virtuella datorerna som körs på den uppleva prestandaproblem.
I ESXTOP visas serverns CPU-belastningsdata överst på skärmen. Utöver den vanliga CPU-belastningen, som inte är särskilt informativ för hypervisorer, finns det ytterligare tre mätvärden:
CORE UTIL(%) – laddar den fysiska serverkärnan. Denna räknare visar hur mycket tid kärnan utfört arbete under mätperioden.
PCPU UTIL(%) – om hypertrådning är aktiverat finns det två trådar (PCPU) per fysisk kärna. Detta mått visar hur lång tid det tog för varje tråd att slutföra arbetet.
PCPU ANVÄND(%) – samma som PCPU UTIL(%), men tar hänsyn till frekvensskalning (antingen minskning av kärnfrekvensen i energibesparingssyfte eller ökning av kärnfrekvensen på grund av Turbo Boost-teknik) och hypertrådning.
PCPU_USED% = PCPU_UTIL% * effektiv kärnfrekvens / nominell kärnfrekvens.
I den här skärmdumpen, för vissa kärnor, på grund av Turbo Boost, är USED-värdet större än 100 %, eftersom kärnfrekvensen är högre än den nominella.
Några ord om hur hyper-threading beaktas. Om processer exekveras 100 % av tiden på båda trådarna i serverns fysiska kärna, medan kärnan arbetar med den nominella frekvensen, då:
- CORE UTIL för kärnan kommer att vara 100 %,
- PCPU UTIL för båda trådarna kommer att vara 100 %,
- PCPU ANVÄND för båda trådarna kommer att vara 50 %.
Om båda gängorna inte fungerade 100 % av tiden under mätperioden, under de perioder då gängorna arbetade parallellt, delas PCPU:n som används för kärnorna på mitten.
ESXTOP har också en skärm med serverns CPU-strömförbrukningsparametrar. Här kan du se om servern använder energibesparande teknologier: C-tillstånd och P-tillstånd. Anropas med "p"-tangenten:
Vanliga CPU-prestandaproblem
Slutligen kommer jag att gå över de typiska orsakerna till problem med VM CPU-prestanda och ge korta tips för att lösa dem:
Kärnens klockhastighet räcker inte. Om det inte går att uppgradera din virtuella dator till mer kraftfulla kärnor kan du prova att ändra effektinställningarna för att få Turbo Boost att fungera mer effektivt.
Felaktig storlek på VM (för många/få kärnor). Om du installerar få kärnor kommer det att bli en hög CPU-belastning på den virtuella datorn. Om det är mycket, ta en hög co-stop.
Stor överteckning av CPU på servern. Om den virtuella datorn har en hög Ready, minska CPU-överabonnemang.
Felaktig NUMA-topologi på stora virtuella datorer. NUMA-topologin som ses av VM (vNUMA) måste matcha NUMA-topologin för servern (pNUMA). Diagnostik och möjliga lösningar på detta problem finns skrivna till exempel i boken . Om du inte vill gå djupare och du inte har licensbegränsningar för operativsystemet installerat på den virtuella datorn, gör många virtuella uttag på den virtuella datorn, en kärna i taget. Du kommer inte att förlora mycket :)
Det är allt för mig om CPU. Fråga frågor. I nästa del kommer jag att prata om RAM.
Användbara länkar
Källa: will.com