Om du administrerar en virtuell infrastruktur baserad pÄ VMware vSphere (eller vilken annan teknikstack som helst), hör du sÀkert ofta anvÀndarnas klagomÄl: "Den virtuella maskinen Àr lÄngsam!". I denna artikelserie kommer jag att gÄ igenom prestationsmetrik och förklara vad som "saktar ner" och hur man kan ÄtgÀrda det.
Jag kommer att behandla följande aspekter av virtuella maskiners prestanda:
- CPU,
- RAM,
- DISK,
- NĂ€tverk.
Jag börjar med CPU.
För att analysera prestandan behöver vi:
- vCenter Performance Counters â prestandaindikatorer vars diagram kan ses via vSphere Client. Information om dessa indikatorer finns tillgĂ€nglig i alla versioner av klienten ("tjocka" klienten i C#, webbklienten i Flex och webbklienten i HTML5). I dessa artiklar kommer vi att anvĂ€nda skĂ€rmbilder frĂ„n C#-klienten, bara för att de ser bĂ€ttre ut i miniatyrform :)
- ESXTOP â ett verktyg som startas frĂ„n kommandoraden i ESXi. Med det kan du fĂ„ vĂ€rden för prestandaindikatorer i realtid eller exportera dessa vĂ€rden under en viss period till en .csv-fil för vidare analys. Jag kommer att berĂ€tta mer om detta verktyg och ge nĂ„gra anvĂ€ndbara lĂ€nkar till dokumentation och artiklar om Ă€mnet.
Lite teori
I ESXi ansvarar en separat process â world i VMware:s terminologi â för varje vCPU (kĂ€rna i den virtuella maskinen). Det finns ocksĂ„ systemprocesser, men nĂ€r det kommer till analys av virtuella maskiners prestanda Ă€r de mindre intressanta.
En process i ESXi kan befinna sig i ett av fyra tillstÄnd:
- Run â processen utför nĂ„got anvĂ€ndbart arbete.
- VĂ€nta â processen utför inget arbete (idle) eller vĂ€ntar pĂ„ in- /utmatning.
- Costop â ett tillstĂ„nd som uppstĂ„r i flera kĂ€rniga virtuella maskiner. Det uppstĂ„r nĂ€r CPU-schemalĂ€ggaren för hypervisor (ESXi CPU Scheduler) inte kan schemalĂ€gga samtidig körning av alla aktiva kĂ€rnor i den virtuella maskinen pĂ„ de fysiska kĂ€rnorna pĂ„ servern. I den fysiska vĂ€rlden fungerar alla kĂ€rnor i processorn parallellt, gĂ€st-OS i VM förvĂ€ntar sig liknande beteende, sĂ„ hypervisorn mĂ„ste sĂ€nka hastigheten pĂ„ VM:s kĂ€rnor som har möjlighet att slutföra cykeln snabbare. I moderna versioner av ESXi anvĂ€nder CPU-schemalĂ€ggaren en mekanism som kallas relaxed co-scheduling: hypervisorn rĂ€knar skillnaden mellan den "snabbaste" och den "lĂ„ngsammaste" kĂ€rnan i den virtuella maskinen (skew). Om skillnaden överstiger en viss tröskel, gĂ„r den "snabba" kĂ€rnan in i tillstĂ„ndet costop. Om VM:s kĂ€rnor befinner sig i detta tillstĂ„nd under lĂ„ng tid kan det orsaka prestandaproblem.
- Redo â processen gĂ„r in i detta tillstĂ„nd nĂ€r hypervisorn inte har möjlighet att tilldela resurser för dess exekvering. Höga vĂ€rden av ready kan orsaka prestandaproblem för VM.
HuvudrÀknare för CPU-prestanda för den virtuella maskinen
CPU-anvÀndning, %. Visar procentandelen av CPU-anvÀndning under en angiven period.
Hur analyserar man? Om VM:n stabilt anvÀnder CPU pÄ 90 % eller har toppar upp till 100 %, sÄ har vi problem. Problemet kan inte bara yttra sig i "lÄngsam" prestanda av applikationen inom VM, utan Àven i VM:ns otillgÀnglighet över nÀtverket. Om övervakningssystemet visar att VM:n periodvis tappar anslutningen, uppmÀrksamma topparna i CPU-anvÀndningsgrafen.
Det finns ett standardlarm som visar CPU-belastningen för den virtuella maskinen:
Vad göra? Om CPU-anvÀndningen stÀndigt överstiger grÀnsen för VM:n kan man övervÀga att öka antalet vCPU (tyvÀrr hjÀlper det inte alltid) eller flytta VM:n till en server med mer kraftfulla processorer.
CPU-anvÀndning i Mhz
I graferna pÄ vCenter kan CPU-anvÀndningen visas i %, men endast för hela den virtuella maskinen, det finns ingen grafer för enskilda kÀrnor (i Esxtop finns det vÀrden i % per kÀrnor). För varje kÀrna kan man se anvÀndningen i MHz.
Hur analyserar man? Det kan hÀnda att en applikation inte Àr optimerad för flerkÀrnig arkitektur: den anvÀnder endast ett kÀrna till 100%, medan övriga stÄr stilla utan belastning. Till exempel, med standardinstÀllningarna för backup kör MS SQL processen endast pÄ ett kÀrn. Resultatet blir att sÀkerhetskopieringen bromsar inte pÄ grund av lÄngsam diskhastighet (detta klagade anvÀndaren inledningsvis pÄ), utan för att processorn inte klarar av det. Problemet löstes genom att Àndra instÀllningarna: backupen började köras parallellt i flera filer (dÀrmed i flera processer).
Exempel pÄ ojÀmn belastning av kÀrnor.
Det kan ocksÄ hÀnda (som i grafen ovan) att kÀrnorna Àr ojÀmnt belastade och pÄ vissa av dem finns toppar pÄ 100%. Precis som med belastning pÄ endast ett kÀrn kommer alarmet för CPU-anvÀndning inte att utlösas (det gÀller hela VM:en), men det kommer att finnas prestandaproblem.
Vad göra? Om programvaran i den virtuella maskinen belastar kÀrnorna ojÀmnt (anvÀnder endast ett kÀrn eller en del av kÀrnorna) Àr det meningslöst att öka antalet. I sÄdana fall Àr det bÀttre att flytta VM:en till en server med mer kraftfulla processorer.
Det kan ocksÄ vara vÀrt att kontrollera instÀllningarna för energiförbrukning i serverns BIOS. MÄnga administratörer aktiverar i BIOS-lÀget High Performance och pÄ sÄ sÀtt inaktiverar energibesparande teknologier som C-states och P-states. Moderna Intel-processorer anvÀnder teknologin Turbo Boost, som ökar frekvensen för vissa kÀrnor pÄ bekostnad av andra kÀrnor. Men den fungerar endast nÀr energibesparande teknologier Àr aktiverade. Om vi stÀnger av dem kan processorn inte minska energiförbrukningen för kÀrnor som inte Àr belastade.
VMware rekommenderar att man inte stÀnger av energibesparande teknologier pÄ servrar, utan att vÀlja lÀgen som maximalt överlÀmnar kontrollen över energiförbrukningen till hypervisorn. I instÀllningarna för energiförbrukning av hypervisorn bör man vÀlja High Performance.
Om du har separata VM:ar (eller kÀrnor av VM:ar) som krÀver en högre CPU-frekvens kan korrekt instÀllning av energiförbrukningen avsevÀrt förbÀttra deras prestanda.
CPU Ready (Bereddhet)
Om vCPU-kÀrnan Àr i ett Ready-tillstÄnd, gör den inget anvÀndbart arbete. Detta tillstÄnd uppstÄr nÀr hypervisorn inte hittar ett ledigt fysiskt kÀrna som kan tilldelas vCPU-processen för den virtuella maskinen.
Hur analyserar man? Generellt, om kÀrnorna för den virtuella maskinen Àr i ett Ready-tillstÄnd mer Àn 10 % av tiden, kommer du att mÀrka prestandaproblem. Enkelt uttryckt, mer Àn 10 % av tiden vÀntar VM pÄ tillgÄngen till fysiska resurser.
I vCenter kan du se tvÄ mÀtvÀrden relaterade till CPU Ready:
- Readiness,
- Ready.
VÀrdena för bÄda mÀtvÀrdena kan ses bÄde för hela VM:n samt för enskilda kÀrnor.
Readiness visar vÀrdet direkt i procent, men endast i realtid (data för den senaste timmen, mÀtintervall pÄ 20 sekunder). Detta mÀtvÀrde bör endast anvÀndas för att hitta problem "pÄ fÀrsk spÄr".
VÀrdena för mÀtvÀrdet Ready kan ocksÄ ses i ett historiskt perspektiv. Detta Àr anvÀndbart för att faststÀlla mönster och för en djupare analys av problemet. Om den virtuella maskinen börjar uppleva prestandaproblem vid en viss tidpunkt, kan man jÀmföra intervallen med förhöjt vÀrde av CPU Ready med den totala belastningen pÄ servern dÀr den aktuella VM:n körs, och vidta ÄtgÀrder för att minska belastningen (om DRS inte klarar det).
Till skillnad frÄn Readiness visas Ready inte i procent, utan i millisekunder. Detta Àr en typ av summationsmÀtvÀrde, vilket betyder att det visar hur mycket tid kÀrnan i VM:n var i ett Ready-tillstÄnd under mÀtperioden. Detta vÀrde kan översÀttas till procent med en enkel formel:
(CPU ready summation value / (chart default update interval in seconds * 1000)) * 100 = CPU ready %
Till exempel, för VM:n i grafen nedan skulle det maximala vÀrdet för Ready för hela den virtuella maskinen bli följande:
Vid berÀkning av vÀrdet för Ready i procent bör tvÄ aspekter beaktas:
- VÀrdet för Ready för hela VM:n Àr summan av Ready för kÀrnorna.
- MÀtningsintervallet. För realtid Àr det 20 sekunder, medan det, till exempel, pÄ dagliga grafer Àr 300 sekunder.
Vid aktiv felsökning kan dessa enkla punkter lÀtt förbises, vilket gör att man slösar vÀrdefull tid pÄ att lösa icke-existerande problem.
Vi berĂ€knar Ready baserat pĂ„ uppgifterna i diagrammet nedan. (324474/(20*1000))*100 = 1622% för hela VM. Om vi ser pĂ„ kĂ€rnorna blir det inte sĂ„ skrĂ€mmande: 1622/64 = 25% per kĂ€rna. I detta fall Ă€r det ganska enkelt att upptĂ€cka en fĂ€lla: vĂ€rdet för Ready Ă€r orealistiskt. Men om det handlar om 10â20% för hela VM med flera kĂ€rnor kan vĂ€rdet per kĂ€rna vara inom det normala.
Vad göra? Ett högt vÀrde pÄ Ready indikerar att servern saknar processorkraft för att virtuella maskiner ska kunna fungera normalt. I en sÄdan situation ÄterstÄr det bara att minska överskridningen av CPU-resurser (vCPU:pCPU). Det Àr uppenbart att detta kan uppnÄs genom att minska parametrarna för befintliga VM eller genom att migrera delar av VM till andra servrar.
Co-stop
Hur analyserar man? Denna rÀknare har ocksÄ typen Summation och översÀtts till procent pÄ samma sÀtt som Ready:
(CPU co-stop summation value / (standard uppdateringsintervall i diagrammet i sekunder * 1000)) * 100 = CPU co-stop %
HÀr behöver vi ocksÄ hÄlla koll pÄ antalet kÀrnor pÄ VM och mÀtintervallet.
I ett co-stop tillstÄnd utför kÀrnan inget nyttigt arbete. Vid rÀtt val av storlek pÄ VM och normal belastning pÄ servern bör co-stop rÀknaren vara nÀra noll.
I detta fall Àr belastningen uppenbart onormal :)
Vad göra? Om flera VM med mÄnga kÀrnor körs pÄ en hypervisor och det finns överskridning av CPU, kan co-stop rÀknaren stiga, vilket kan leda till prestandaproblem för dessa VM.
Co-stop kommer ocksÄ att öka om aktiva kÀrnor pÄ en VM anvÀnder trÄdar pÄ ett fysiskt kÀrna pÄ servern med hyperthreading aktiverat. En sÄdan situation kan uppstÄ om VM har fler kÀrnor Àn vad som fysiskt finns pÄ servern dÀr den körs, eller om VM Àr instÀlld pÄ "preferHT". Du kan lÀsa mer om denna instÀllning. .
För att undvika prestandaproblem för VM pÄ grund av hög co-stop, vÀlj storleken pÄ VM enligt tillverkarens rekommendationer för programvaran som körs pÄ denna VM och med kapaciteten hos den fysiska servern dÀr VM körs.
LÀgg inte till kÀrnor i förvar, det kan orsaka prestandaproblem inte bara för VM sjÀlv utan Àven för dess grannar pÄ servern.
Andra anvÀndbara CPU-metriker
Run â hur mycket tid (ms) under mĂ€tperioden vCPU befann sig i tillstĂ„ndet RUN, det vill sĂ€ga faktiskt utförde nyttigt arbete.
Idle â hur mycket tid (ms) under mĂ€tperioden som vCPU varit i ett inaktivt tillstĂ„nd. Höga vĂ€rden för Idle Ă€r inget problem, det betyder bara att vCPU hade "inget att göra".
VĂ€nta â hur mycket tid (ms) under mĂ€tperioden som vCPU varit i ett vĂ€ntande tillstĂ„nd. Eftersom detta mĂ€tvĂ€rde inkluderar IDLE, indikerar höga vĂ€rden för Wait inte heller ett problem. Men om Wait Ă€r högt och IDLE lĂ„gt, innebĂ€r det att VM vĂ€ntade pĂ„ att I/O-operationer skulle slutföras, vilket kan tyda pĂ„ ett prestandaproblem med hĂ„rddisken eller nĂ„gra virtuella enheter i VM.
Max begrĂ€nsad â hur mycket tid (ms) under mĂ€tperioden som vCPU varit i ett Ready-tillstĂ„nd pĂ„ grund av en resursbegrĂ€nsning. Om prestandan Ă€r oförklarligt lĂ„g, Ă€r det bra att kontrollera detta mĂ€tvĂ€rde och CPU-begrĂ€nsningen i VM:ns instĂ€llningar. Det kan finnas begrĂ€nsningar pĂ„ VM som du inte kĂ€nner till. Till exempel kan detta hĂ€nda nĂ€r VM har klonats frĂ„n en mall dĂ€r en CPU-begrĂ€nsning har stĂ€llts in.
Swap wait â hur lĂ€nge under mĂ€tperioden som vCPU vĂ€ntade pĂ„ operationer med VMkernel Swap. Om detta mĂ€tvĂ€rde Ă€r större Ă€n noll, har VM definitivt prestandaproblem. Mer om SWAP kommer vi att diskutera i artikeln om minnesmĂ€tare.
ESXTOP
Om prestandaindikatorerna i vCenter Àr bra för att analysera historiska data, Àr det bÀttre att göra en snabb analys av problemet i ESXTOP. HÀr presenteras alla vÀrden i ett fÀrdigt format (inget översÀttning behövs), och den minimi mÀtperioden Àr 2 sekunder.
ESXTOP-skÀrmen för CPU öppnas med tangenten "c" och ser ut pÄ följande sÀtt:
För att förenkla kan du lÀmna kvar endast processerna för virtuella maskiner genom att trycka pÄ Shift-V.
För att se metrik för individuella kÀrnor i VM, tryck pÄ "e" och ange GID för den intressanta VM (30919 pÄ skÀrmbilden nedan):
Jag gÄr kort igenom de kolumner som finns som standard. Ytterligare kolumner kan lÀggas till genom att trycka pÄ "f".
NWLD (Antal vĂ€rldar) â antalet processer i gruppen. För att expandera gruppen och se metrik för varje process (till exempel för varje kĂ€rna i en flertrĂ„dad VM), tryck pĂ„ âeâ. Om det finns mer Ă€n en process i gruppen Ă€r metrikvĂ€rdena för gruppen summan av metrikvĂ€rdena för de enskilda processerna.
%ANVĂND â hur mĂ„nga CPU-cykler servern anvĂ€nder för processen eller gruppen av processer.
%KĂR â hur lĂ€nge processen under mĂ€tperioden var i tillstĂ„ndet RUN, det vill sĂ€ga utförde nyttigt arbete. Skiljer sig frĂ„n %USED genom att det inte tar hĂ€nsyn till hyper-threading, frekvensskalning och tid som anvĂ€nds för systemuppgifter (%SYS).
%SYS â tid som spenderas pĂ„ systemuppgifter, till exempel: hantering av avbrott, in-/utdata, nĂ€tverksarbete etc. VĂ€rdet kan vara högre om VM har hög in-/utdata.
%OVRLP â hur lĂ€nge den fysiska kĂ€rnan som kör VM-processen har spenderat pĂ„ uppgifter frĂ„n andra processer.
Dessa metrikar relaterar till varandra pÄ följande sÀtt:
%USED = %RUN + %SYS â %OVRLP.
Vanligtvis Àr metrik %USED mer informativ.
%WAIT â hur lĂ€nge processen under mĂ€tperioden var i tillstĂ„ndet Wait. Inkluderar IDLE.
%IDLE â hur lĂ€nge processen under mĂ€tperioden var i tillstĂ„ndet IDLE.
%SWPWT â hur lĂ€nge vCPU under mĂ€tperioden vĂ€ntade pĂ„ swap-operationer med VMkernel.
%VMWAIT â hur lĂ€nge vCPU under mĂ€tperioden var i tillstĂ„ndet vĂ€ntar pĂ„ ett hĂ€ndelse (vanligtvis in-/utdata). Det finns ingen liknande rĂ€knare i vCenter. Höga vĂ€rden indikerar problem med in-/utdata pĂ„ VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Om VM inte anvÀnder VMkernel Swap, Àr det meningsfullt att fokusera pÄ %VMWAIT vid analys av prestandaproblem, eftersom denna metrik inte tar hÀnsyn till tiden dÄ VM inte gjorde nÄgot (%IDLE).
%RDY â hur lĂ€nge processen under mĂ€tperioden var i tillstĂ„ndet Ready.
%CSTP â hur lĂ€nge processen under mĂ€tperioden var i tillstĂ„ndet costop.
%MLMTD â hur lĂ€nge vCPU under mĂ€tperioden var i tillstĂ„ndet Ready pĂ„ grund av resursbegrĂ€nsning.
%WAIT + %RDY + %CSTP + %RUN = 100% â en kĂ€rna i VM Ă€r hela tiden i ett av dessa fyra tillstĂ„nd.
CPU pÄ hypervisorn
I vCenter finns Ă€ven prestandarĂ€knare för CPU pĂ„ hypervisorn, men de Ă€r inget intressant â det Ă€r bara summan av rĂ€knarna för alla VM pĂ„ servern.
Det Àr enklast att se CPU-tillstÄndet pÄ servern under fliken Sammanfattning:
För en server, precis som för en virtuell maskin, finns det en standardlarm:
Vid hög belastning pÄ serverns CPU, börjar VM som körs pÄ den fÄ prestandaproblem.
I ESXTOP visas uppgifter om CPU-belastningen pÄ servern presenteras i övre delen av skÀrmen. Förutom standard CPU-belastning, som Àr lite informativ för hypervisorer, finns det tre ytterligare mÄtt:
KĂRNA UTIL(%) â belastning pĂ„ kĂ€rnan i den fysiska servern. Denna mĂ€tare visar hur mycket tid kĂ€rnan har utfört arbete under mĂ€tperioden.
PCPU UTIL(%) â om hyper-threading Ă€r aktiverat, sĂ„ har varje fysisk kĂ€rna tvĂ„ trĂ„dar (PCPU). Detta mĂ„tt visar hur mycket tid varje trĂ„d har utfört arbete.
PCPU ANVĂND(%) â samma som PCPU UTIL(%), men tar hĂ€nsyn till frekvensskalning (antingen minskning av kĂ€rnfrekvensen för energibesparing eller ökning av kĂ€rnfrekvensen tack vare Turbo Boost) och hyper-threading.
PCPU_ANVĂND% = PCPU_UTIL% * effektiv kĂ€rnfrekvens / nominell kĂ€rnfrekvens.
I den hĂ€r skĂ€rmdumpen Ă€r vĂ€rdet ANVĂND för vissa kĂ€rnor över 100% pĂ„ grund av Turbo Boost, eftersom kĂ€rnfrekvensen Ă€r högre Ă€n nominell.
Ett par ord om hur hyper-threading beaktas. Om processerna körs 100% av tiden pÄ bÄda trÄdarna i den fysiska kÀrnan, och kÀrnan arbetar med nominell frekvens, sÄ:
- KĂRNA UTIL för kĂ€rnan blir 100%,
- PCPU UTIL för bÄda trÄdarna blir 100%,
- PCPU ANVĂND för bĂ„da trĂ„darna blir 50%.
Om bĂ„da trĂ„darna inte arbetade 100% av tiden under mĂ€tperioden, dĂ„ delas PCPU ANVĂND för kĂ€rnorna upp i hĂ€lften under de perioder dĂ„ trĂ„darna arbetade parallellt.
I ESXTOP finns Àven en skÀrm för energiförbrukningsinstÀllningar för serverns CPU. HÀr kan du se om servern anvÀnder energibesparingstekniker: C-states och P-states. à tkomst via knappen "p":
Standardproblem med CPU-prestanda
Till sist gÄr jag igenom typiska orsaker till problem med CPU-prestanda i VM och ger korta tips om hur man kan ÄtgÀrda dem:
Det finns inte tillrÀckligt med kÀrnfrekvens. Om det inte gÄr att flytta VM till mer kraftfulla kÀrnor kan du försöka Àndra energisparinstÀllningarna sÄ att Turbo Boost fungerar effektivare.
Felaktig sizing av VM (för mÄnga/fÄ kÀrnor). Om du sÀtter för fÄ kÀrnor, kommer CPU-belastningen pÄ VM att vara hög. Om du sÀtter för mÄnga, kommer du att fÄ hög co-stop.
Stor överskrivning av CPU pÄ servern. Om VM har hög Ready, minska CPU-överskrivningen.
Felaktig NUMA-topologi pĂ„ stora VM. NUMA-topologi som VMen (vNUMA) ser ska motsvara serverns NUMA-topologi (pNUMA). Om diagnosticering och möjliga lösningar pĂ„ detta problem, till exempel, kan lĂ€sas i boken . Om du inte vill gĂ„ pĂ„ djupet och inte har nĂ„gra licensbegrĂ€nsningar för operativsystemet som Ă€r installerat pĂ„ VMen, skapa gĂ€rna flera virtuella socklar med ett kĂ€rna per socket. Du kommer att förlora mycket đ
Det Àr allt om CPU för mig. StÀll gÀrna frÄgor. I nÀsta del kommer jag att berÀtta om det operativa minnet.
Nyttiga lÀnkar
KĂ€lla: habr.com
