As jy 'n virtuele infrastruktuur administreer gebaseer op VMware vSphere (of enige ander tegnologiestapel), hoor jy waarskynlik dikwels klagtes van gebruikers: "Die virtuele masjien is stadig!" In hierdie reeks artikels sal ek prestasiemaatstawwe ontleed en jou vertel wat en hoekom dit vertraag en hoe om seker te maak dat dit nie vertraag nie.
Ek sal die volgende aspekte van virtuele masjien se werkverrigting oorweeg:
- SVE,
- RAM,
- SKYF,
- Netwerk.
Ek sal met die SVE begin.
Om prestasie te ontleed sal ons nodig hê:
- vCenter Prestasietellers – prestasietellers, waarvan die grafieke deur die vSphere Client bekyk kan word. Inligting oor hierdie tellers is beskikbaar in enige weergawe van die kliënt (“dik” kliënt in C#, webkliënt in Flex en webkliënt in HTML5). In hierdie artikels sal ons skermkiekies van die C#-kliënt gebruik, net omdat dit beter lyk in miniatuur :)
- ESXTOP – 'n program wat vanaf die ESXi-opdragreël loop. Met sy hulp kan jy die waardes van prestasietellers intyds kry of hierdie waardes vir 'n sekere tydperk in 'n .csv-lêer oplaai vir verdere ontleding. Vervolgens vertel ek jou meer oor hierdie hulpmiddel en verskaf verskeie nuttige skakels na dokumentasie en artikels oor die onderwerp.
'N bietjie teorie
In ESXi is 'n aparte proses - wêreld in VMware-terminologie - verantwoordelik vir die werking van elke vCPU (virtuele masjienkern). Daar is ook diensprosesse, maar vanuit die oogpunt van die ontleding van VM-prestasie is dit minder interessant.
'n Proses in ESXi kan in een van vier state wees:
- Run – die proses verrig nuttige werk.
- Wag – die proses doen geen werk nie (ledig) of wag vir invoer/uitvoer.
- Costop – 'n toestand wat voorkom in multi-kern virtuele masjiene. Dit vind plaas wanneer die hypervisor SVE skeduleerder (ESXi CPU Scheduler) nie die gelyktydige uitvoering van alle aktiewe virtuele masjien kerne op die fisiese bediener kerne kan skeduleer nie. In die fisiese wêreld werk alle verwerkerkerne in parallel, die gas-bedryfstelsel binne die VM verwag soortgelyke gedrag, so die hiperviser moet die VM-kerne vertraag wat die vermoë het om hul kloksiklus vinniger te voltooi. In moderne weergawes van ESXi gebruik die SVE-skeduleerder 'n meganisme genaamd ontspanne mede-skedulering: die hiperviseerder beskou die gaping tussen die "vinnigste" en die "stadigste" virtuele masjienkern (skeef). As die gaping 'n sekere drempel oorskry, gaan die vinnige kern die kostestaat binne. As VM-kerne baie tyd in hierdie toestand deurbring, kan dit prestasieprobleme veroorsaak.
- Ready – die proses gaan hierdie toestand in wanneer die hiperviser nie in staat is om hulpbronne vir die uitvoering daarvan toe te ken nie. Hoë gereedwaardes kan VM-werkverrigtingprobleme veroorsaak.
Basiese virtuele masjien SVE werkverrigting tellers
SVE-gebruik, %. Toon die persentasie SVE-gebruik vir 'n gegewe tydperk.
Hoe om te ontleed? As 'n VM konsekwent SVE teen 90% gebruik of daar pieke tot 100% is, dan het ons probleme. Probleme kan nie net uitgedruk word in die "stadige" werking van die toepassing binne die VM nie, maar ook in die ontoeganklikheid van die VM oor die netwerk. As die moniteringstelsel wys dat die VM periodiek afval, let op die pieke in die SVE-gebruikgrafiek.
Daar is 'n standaard alarm wat die SVE-lading van die virtuele masjien wys:
Wat om te doen? As 'n VM se SVE-gebruik voortdurend deur die dak gaan, kan jy daaraan dink om die aantal vCPU's te verhoog (ongelukkig help dit nie altyd nie) of om die VM na 'n bediener met kragtiger verwerkers te skuif.
SVE-gebruik in MHz
In die grafieke op vCenter Gebruik in % kan jy slegs vir die hele virtuele masjien sien; daar is geen grafieke vir individuele kerns nie (in Esptop is daar % waardes vir kerns). Vir elke kern kan jy Gebruik in MHz sien.
Hoe om te ontleed? Dit gebeur dat 'n toepassing nie vir 'n multi-kern argitektuur geoptimaliseer is nie: dit gebruik slegs een kern 100%, en die res is ledig sonder vrag. Byvoorbeeld, met verstekrugsteuninstellings, begin MS SQL die proses op slegs een kern. As gevolg hiervan vertraag die rugsteun nie as gevolg van die stadige spoed van die skywe nie (dit is waaroor die gebruiker aanvanklik gekla het), maar omdat die verwerker dit nie kan hanteer nie. Die probleem is opgelos deur die parameters te verander: rugsteun het parallel begin loop in verskeie lêers (onderskeidelik in verskeie prosesse).
'n Voorbeeld van ongelyke lading op kerns.
Daar is ook 'n situasie (soos in die grafiek hierbo) wanneer die kerns oneweredig gelaai word en sommige van hulle het pieke van 100%. Soos met die laai van slegs een kern, sal die alarm vir SVE-gebruik nie werk nie (dit is vir die hele VM), maar daar sal werkverrigtingprobleme wees.
Wat om te doen? As die sagteware in 'n virtuele masjien die kerns oneweredig laai (gebruik slegs een kern of 'n deel van die kerns), is dit geen sin om hul aantal te vermeerder nie. In hierdie geval is dit beter om die VM na 'n bediener met kragtiger verwerkers te skuif.
Jy kan ook probeer om die kragverbruikinstellings in die bediener se BIOS na te gaan. Baie administrateurs aktiveer Hoëprestasiemodus in die BIOS en deaktiveer daardeur C-state en P-state energiebesparende tegnologieë. Moderne Intel-verwerkers gebruik Turbo Boost-tegnologie, wat die frekwensie van individuele verwerkerkerne verhoog ten koste van ander kerne. Maar dit werk net wanneer energiebesparende tegnologieë aangeskakel is. As ons dit deaktiveer, kan die verwerker nie die kragverbruik van kerne wat nie gelaai is nie verminder nie.
VMware beveel aan om nie kragbesparende tegnologieë op bedieners te deaktiveer nie, maar om modusse te kies wat kragbestuur soveel as moontlik aan die hiperviser oorlaat. In hierdie geval, in die hipervisor-kragverbruikinstellings, moet jy Hoë Werkverrigting kies.
As jy individuele VM's (of VM-kerne) in jou infrastruktuur het wat verhoogde SVE-frekwensie vereis, kan die korrekte aanpassing van kragverbruik hul werkverrigting aansienlik verbeter.
SVE Gereed
As die VM-kern (vCPU) in die Gereed-toestand is, verrig dit nie nuttige werk nie. Hierdie toestand vind plaas wanneer die hypervisor nie 'n vrye fisiese kern vind waaraan die virtuele masjien se vCPU-proses toegewys kan word nie.
Hoe om te ontleed? Tipies, as 'n virtuele masjien se kerns meer as 10% van die tyd in die Gereed-toestand is, sal jy prestasieprobleme opmerk. Eenvoudig gestel, meer as 10% van die tyd wag die VM vir fisiese hulpbronne om beskikbaar te word.
In vCenter kan jy 2 tellers sien wat verband hou met CPU Ready:
- gereedheid,
- Gereed.
Die waardes van beide tellers kan beide vir die hele VM en vir individuele kerns bekyk word.
Gereedheid toon die waarde onmiddellik as 'n persentasie, maar slegs in Real-time (data vir die laaste uur, metingsinterval 20 sekondes). Dit is beter om hierdie toonbank net te gebruik om probleme "warm op die hakke" te soek.
Gereed-teenwaardes kan ook vanuit 'n historiese perspektief gesien word. Dit is nuttig vir die vestiging van patrone en vir dieper ontleding van die probleem. Byvoorbeeld, as 'n virtuele masjien op 'n sekere tyd werkverrigtingprobleme begin ervaar, kan jy die intervalle van die CPU Ready-waarde vergelyk met die totale las op die bediener waar hierdie VM loop, en maatreëls tref om die las te verminder (indien DRS misluk).
Gereed, anders as gereedheid, word nie in persentasies getoon nie, maar in millisekondes. Dit is 'n Opsomming tipe teller, dit wil sê, dit wys hoe lank gedurende die metingsperiode die VM-kern in die Gereed-toestand was. U kan hierdie waarde in 'n persentasie omskakel deur 'n eenvoudige formule te gebruik:
(SVE gereed opsomming waarde / (grafiek verstek opdatering interval in sekondes * 1000)) * 100 = SVE gereed %
Byvoorbeeld, vir die VM in die grafiek hieronder, sal die piek gereed-waarde vir die hele virtuele masjien soos volg wees:
Wanneer u die gereed-persentasie bereken, moet u op twee punte let:
- Die Ready-waarde vir die hele VM is die som van Ready oor kerns heen.
- Meet interval. Vir Real-time is dit 20 sekondes, en, byvoorbeeld, op daaglikse kaarte is dit 300 sekondes.
Met aktiewe foutsporing kan hierdie eenvoudige punte maklik gemis word en kan waardevolle tyd gemors word op die oplossing van nie-bestaande probleme.
Kom ons bereken Ready gebaseer op die data van die grafiek hieronder. (324474/(20*1000))*100 = 1622% vir die hele VM. As jy na die kerns kyk, is dit nie so skrikwekkend nie: 1622/64 = 25% per kern. In hierdie geval is die vangs redelik maklik om raak te sien: die Ready-waarde is onrealisties. Maar as ons praat van 10–20% vir die hele VM met verskeie kerns, dan kan die waarde vir elke kern binne die normale omvang wees.
Wat om te doen? 'n Hoë Ready-waarde dui aan dat die bediener nie genoeg verwerkerhulpbronne het vir die normale werking van virtuele masjiene nie. In so 'n situasie is al wat oorbly om oorintekening deur verwerker (vCPU:pCPU) te verminder. Dit kan natuurlik bereik word deur die parameters van bestaande VM's te verminder of deur 'n deel van die VM's na ander bedieners te migreer.
Medestop
Hoe om te ontleed? Hierdie teller is ook van die Opsomming tipe en word omgeskakel na persentasies op dieselfde manier as Gereed:
(SVE medestop-opsommingwaarde / (grafiek verstek opdateringsinterval in sekondes * 1000)) * 100 = SVE medestop %
Hier moet jy ook aandag gee aan die aantal kerne op die VM en die metingsinterval.
In die costop-toestand verrig die kern nie nuttige werk nie. Met die korrekte keuse van die VM-grootte en normale las op die bediener, behoort die medestop-teller naby aan nul te wees.
In hierdie geval is die vrag duidelik abnormaal :)
Wat om te doen? As verskeie VM's met 'n groot aantal kerns op een hipervisor loop en daar is oorintekening op die SVE, dan kan die medestop-teller toeneem, wat sal lei tot probleme met die werkverrigting van hierdie VM's.
Mede-stop sal ook toeneem as die aktiewe kerns van een VM drade op een fisiese bedienerkern gebruik met hipertraping geaktiveer. Hierdie situasie kan byvoorbeeld ontstaan as die VM meer kerne het as wat fisies beskikbaar is op die bediener waar dit loop, of as die "preferHT"-instelling vir die VM geaktiveer is. Jy kan lees oor hierdie instelling .
Om probleme met VM-werkverrigting as gevolg van hoë medestop te vermy, kies die VM-grootte in ooreenstemming met die aanbevelings van die vervaardiger van die sagteware wat op hierdie VM loop en die vermoëns van die fisiese bediener waar die VM loop.
Moenie kerns in reserwe byvoeg nie; dit kan werkverrigtingprobleme veroorsaak, nie net vir die VM self nie, maar ook vir sy bure op die bediener.
Ander nuttige SVE-statistieke
Run – hoeveel tyd (ms) gedurende die metingsperiode die vCPU in die RUN-toestand was, dit wil sê, dit het eintlik nuttige werk verrig.
idle – hoe lank (ms) gedurende die metingsperiode die vCPU in 'n toestand van onaktiwiteit was. Hoë ledige waardes is nie 'n probleem nie, die vCPU het net "niks om te doen" gehad nie.
Wag – hoe lank (ms) gedurende die metingsperiode die vCPU in die wagtoestand was. Aangesien IDLE by hierdie teller ingesluit is, dui hoë wagwaardes ook nie op 'n probleem nie. Maar as Wait IDLE laag is wanneer Wait hoog is, beteken dit dat die VM gewag het vir I/O-bewerkings om te voltooi, en dit kan op sy beurt 'n probleem met die werkverrigting van die hardeskyf of enige virtuele toestelle van die VM aandui.
Maks beperk – hoe lank (ms) gedurende die metingsperiode die vCPU in die Gereed-toestand was as gevolg van die vasgestelde hulpbronlimiet. As werkverrigting onverklaarbaar laag is, is dit nuttig om die waarde van hierdie teller en die SVE-limiet in die VM-instellings na te gaan. VM'e kan inderdaad perke hê waarvan jy nie bewus is nie. Byvoorbeeld, dit gebeur wanneer 'n VM gekloon is vanaf 'n sjabloon waarop die SVE-limiet gestel is.
Ruil wag – hoe lank gedurende die metingsperiode die vCPU gewag het vir 'n bewerking met VMkernel Swap. As die waardes van hierdie teller bo nul is, het die VM beslis prestasieprobleme. Ons sal meer oor SWAP praat in die artikel oor RAM-tellers.
ESXTOP
As prestasietellers in vCenter goed is vir die ontleding van historiese data, dan is operasionele analise van die probleem beter in ESXTOP gedoen. Hier word alle waardes in klaargemaakte vorm aangebied (nie nodig om iets te vertaal nie), en die minimum meetperiode is 2 sekondes.
Die ESXTOP-skerm vir SVE word met die "c"-sleutel opgeroep en lyk so:
Gerieflikheidshalwe kan u slegs virtuele masjienprosesse verlaat deur Shift-V te druk.
Om statistieke vir individuele VM-kerns te sien, druk "e" en voer die GID van die VM van belang in (30919 in die skermkiekie hieronder):
Laat ek kortliks deur die kolomme gaan wat by verstek aangebied word. Bykomende kolomme kan bygevoeg word deur "f" te druk.
NWLD (aantal wêrelde) – aantal prosesse in die groep. Om die groep uit te brei en statistieke vir elke proses te sien (byvoorbeeld vir elke kern in 'n multi-kern VM), druk "e". As daar meer as een proses in 'n groep is, dan is die metrieke waardes vir die groep gelyk aan die som van die metrieke vir die individuele prosesse.
%GEBRUIK – hoeveel bediener-SVE-siklusse word deur 'n proses of groep prosesse gebruik.
%LOOP – hoe lank gedurende die meetperiode die proses in die RUN-toestand was, m.a.w. nuttige werk gedoen het. Dit verskil van %USED deurdat dit nie hiper-threading, frekwensieskaal en tyd spandeer aan stelseltake (%SYS) in ag neem nie.
%SYS – tyd wat aan stelseltake bestee word, byvoorbeeld: onderbrekingsverwerking, I/O, netwerkwerking, ens. Die waarde kan hoog wees as die VM 'n groot I/O het.
%OVRLP – hoeveel tyd die fisiese kern waarop die VM-proses loop, spandeer aan take van ander prosesse.
Hierdie maatstawwe hou soos volg met mekaar verband:
%GEBRUIK = %LOOP + %SYS - %OVRLP.
Tipies is die %USED-metriek meer insiggewend.
%WAG – hoe lank gedurende die metingsperiode die proses in die wagtoestand was. Aktiveer IDLE.
%IDLE – hoe lank gedurende die metingsperiode die proses in die IDLE-toestand was.
%SWPWT – hoe lank gedurende die metingsperiode die vCPU gewag het vir 'n bewerking met VMkernel Swap.
%VMWAIT – hoe lank gedurende die metingsperiode die vCPU in die toestand was van wag vir 'n gebeurtenis (gewoonlik I/O). Daar is geen soortgelyke teller in vCenter nie. Hoë waardes dui probleme met I/O op die VM aan.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
As die VM nie VMkernel Swap gebruik nie, is dit raadsaam om na %VMWAIT te kyk wanneer prestasieprobleme ontleed word, aangesien hierdie maatstaf nie die tyd in ag neem toe die VM niks gedoen het nie (%IDLE).
%RDY – hoe lank gedurende die meetperiode die proses in die Gereed-toestand was.
%CSTP – hoe lank gedurende die metingsperiode die proses in die kostestaat was.
%MLMTD – hoe lank gedurende die metingsperiode die vCPU in die Gereed-toestand was as gevolg van die vasgestelde hulpbronlimiet.
%WAIT + %RDY + %CSTP + %RUN = 100% – die VM-kern is altyd in een van hierdie vier toestande.
SVE op hypervisor
vCenter het ook SVE-werkverrigtingtellers vir die hiperviser, maar dit is niks interessant nie - dit is bloot die som van die tellers vir alle VM's op die bediener.
Die gerieflikste manier om die SVE-status op die bediener te sien, is op die Opsomming-oortjie:
Vir die bediener, sowel as vir die virtuele masjien, is daar 'n standaard Alarm:
Wanneer die bediener SVE-lading hoog is, begin die VM's wat daarop loop, werkverrigtingprobleme ervaar.
In ESXTOP word bediener SVE-laaidata boaan die skerm aangebied. Benewens die standaard SVE-lading, wat nie baie insiggewend is vir hiperviseerders nie, is daar nog drie maatstawwe:
KERNBUTIL(%) – laai die fisiese bedienerkern. Hierdie teller wys hoeveel tyd die kern gedurende die metingsperiode werk verrig het.
PCPU UTIL(%) – as hiper-threading geaktiveer is, dan is daar twee drade (PCPU) per fisiese kern. Hierdie maatstaf wys hoe lank elke draad geneem het om werk te voltooi.
PCPU GEBRUIK(%) – dieselfde as PCPU UTIL(%), maar neem frekwensieskaal in ag (óf die vermindering van die kernfrekwensie vir energiebesparingsdoeleindes, óf die verhoging van die kernfrekwensie as gevolg van Turbo Boost-tegnologie) en hiper-threading.
PCPU_USED% = PCPU_UTIL% * effektiewe kernfrekwensie / nominale kernfrekwensie.
In hierdie skermkiekie, vir sommige kerns, as gevolg van Turbo Boost, is die GEBRUIKTE waarde groter as 100%, aangesien die kernfrekwensie hoër is as die nominale een.
'n Paar woorde oor hoe hiper-threading in ag geneem word. As prosesse 100% van die tyd op beide drade van die bediener se fisiese kern uitgevoer word, terwyl die kern op die nominale frekwensie werk, dan:
- CORE UTIL vir die kern sal 100% wees,
- PCPU UTIL vir beide drade sal 100% wees,
- PCPU GEBRUIK vir beide drade sal 50% wees.
As beide drade nie 100% van die tyd gedurende die metingsperiode gewerk het nie, word die PCPU GEBRUIK vir die kerns in die helfte gedeel gedurende daardie periodes wanneer die drade parallel gewerk het.
ESXTOP het ook 'n skerm met bediener SVE kragverbruik parameters. Hier kan jy sien of die bediener energiebesparende tegnologieë gebruik: C-toestande en P-toestande. Gebel met die "p" sleutel:
Algemene SVE-prestasiekwessies
Laastens gaan ek oor die tipiese oorsake van probleme met VM-SVE-werkverrigting en gee kort wenke om dit op te los:
Die kernklokspoed is nie genoeg nie. As dit nie moontlik is om jou VM na kragtiger kerns op te gradeer nie, kan jy probeer om die kraginstellings te verander om Turbo Boost doeltreffender te laat werk.
Verkeerde VM-grootte (te veel/min kerns). As jy min kerne installeer, sal daar 'n hoë SVE-lading op die VM wees. As daar baie is, vang 'n hoë medestop.
Groot oorintekening van SVE op die bediener. As die VM 'n hoë gereed het, verminder SVE-oorintekening.
Verkeerde NUMA-topologie op groot VM'e. Die NUMA-topologie wat deur die VM (vNUMA) gesien word, moet ooreenstem met die NUMA-topologie van die bediener (pNUMA). Diagnostiek en moontlike oplossings vir hierdie probleem word byvoorbeeld in die boek geskryf . As jy nie dieper wil gaan nie en jy het nie lisensiebeperkings op die bedryfstelsel op die VM geïnstalleer nie, maak baie virtuele voetstukke op die VM, een kern op 'n slag. Jy sal nie veel verloor nie :)
Dit is alles vir my oor die SVE. Vra vrae. In die volgende deel sal ek oor RAM praat.
nuttige skakels
Bron: will.com