Als je een virtuele infrastructuur beheert op basis van VMware vSphere (of een andere technologiestack), hoor je waarschijnlijk vaak klachten van gebruikers: “De virtuele machine is traag!” In deze serie artikelen analyseer ik prestatiestatistieken en vertel ik wat en waarom het vertraagt en hoe je ervoor kunt zorgen dat het niet vertraagt.
Ik zal de volgende aspecten van de prestaties van virtuele machines bekijken:
- CPU,
- RAM,
- SCHIJF,
- Netwerk.
Ik begin met de CPU.
Om de prestaties te analyseren hebben we het volgende nodig:
- vCenter-prestatiemeteritems – prestatietellers, waarvan de grafieken via de vSphere Client te bekijken zijn. Informatie over deze tellers is beschikbaar in elke versie van de client (“thick” client in C#, webclient in Flex en webclient in HTML5). In deze artikelen gebruiken we screenshots van de C#-client, alleen omdat ze er in miniatuur beter uitzien :)
- ESXTOP – een hulpprogramma dat wordt uitgevoerd vanaf de ESXi-opdrachtregel. Met zijn hulp kunt u de waarden van prestatietellers in realtime opvragen of deze waarden voor een bepaalde periode uploaden naar een .csv-bestand voor verdere analyse. Vervolgens vertel ik je meer over deze tool en geef ik een aantal nuttige links naar documentatie en artikelen over dit onderwerp.
Een beetje theorie
In ESXi is een apart proces – wereld in VMware-terminologie – verantwoordelijk voor de werking van elke vCPU (virtuele machinekern). Er zijn ook serviceprocessen, maar vanuit het oogpunt van het analyseren van VM-prestaties zijn deze minder interessant.
Een proces in ESXi kan zich in een van de volgende vier toestanden bevinden:
- lopen – het proces verricht nuttig werk.
- Wacht – het proces doet geen werk (inactief) of wacht op invoer/uitvoer.
- Kosten – een aandoening die optreedt bij virtuele machines met meerdere kernen. Het treedt op wanneer de CPU-planner van de hypervisor (ESXi CPU Scheduler) de gelijktijdige uitvoering van alle actieve virtuele machinekernen op de fysieke serverkernen niet kan plannen. In de fysieke wereld werken alle processorcores parallel, het gastbesturingssysteem in de VM verwacht soortgelijk gedrag, dus de hypervisor moet de VM-cores vertragen die de mogelijkheid hebben om hun klokcyclus sneller te voltooien. In moderne versies van ESXi gebruikt de CPU-planner een mechanisme dat ontspannen co-scheduling wordt genoemd: de hypervisor houdt rekening met de kloof tussen de “snelste” en de “langzaamste” kern van de virtuele machine (skew). Als de kloof een bepaalde drempel overschrijdt, komt de snelle kern in de costop-status. Als VM-kernen veel tijd in deze staat doorbrengen, kan dit prestatieproblemen veroorzaken.
- Klaar – het proces komt in deze toestand terecht wanneer de hypervisor niet in staat is middelen toe te wijzen voor de uitvoering ervan. Hoge gereedwaarden kunnen VM-prestatieproblemen veroorzaken.
Basis CPU-prestatietellers voor virtuele machines
CPU gebruik, %. Toont het percentage CPU-gebruik voor een bepaalde periode.
Hoe analyseren? Als een VM consistent CPU op 90% gebruikt of er pieken zijn tot 100%, dan hebben we problemen. Problemen kunnen zich niet alleen uiten in de “trage” werking van de applicatie binnen de VM, maar ook in de ontoegankelijkheid van de VM via het netwerk. Als uit het monitoringsysteem blijkt dat de VM periodiek uitvalt, let dan op de pieken in de CPU-gebruiksgrafiek.
Er is een standaardalarm dat de CPU-belasting van de virtuele machine toont:
Wat te doen? Als het CPU-gebruik van een VM voortdurend de pan uit rijt, kun je nadenken over het verhogen van het aantal vCPU’s (helaas helpt dit niet altijd) of het verplaatsen van de VM naar een server met krachtigere processors.
CPU-gebruik in MHz
In de grafieken op vCenter Usage in % kun je alleen voor de gehele virtuele machine zien; er zijn geen grafieken voor individuele cores (in Esxtop zijn er %-waarden voor cores). Voor elke kern ziet u het gebruik in MHz.
Hoe analyseren? Het komt voor dat een applicatie niet is geoptimaliseerd voor een multi-core architectuur: deze gebruikt slechts één core 100%, en de rest is inactief zonder belasting. Met standaard back-upinstellingen start MS SQL het proces bijvoorbeeld op slechts één kern. Als gevolg hiervan vertraagt de back-up niet vanwege de lage snelheid van de schijven (dit is waar de gebruiker aanvankelijk over klaagde), maar omdat de processor het niet aankan. Het probleem werd opgelost door de parameters te wijzigen: de back-up begon parallel te draaien in verschillende bestanden (respectievelijk in verschillende processen).
Een voorbeeld van ongelijkmatige belasting van kernen.
Er is ook een situatie (zoals in de grafiek hierboven) waarin de kernen ongelijkmatig worden belast en sommige pieken van 100% hebben. Net als bij het laden van slechts één kern, zal het alarm voor CPU-gebruik niet werken (het is voor de hele VM), maar er zullen prestatieproblemen zijn.
Wat te doen? Als de software in een virtuele machine de kernen ongelijkmatig laadt (slechts één kern of een deel van de kernen gebruikt), heeft het geen zin om hun aantal te vergroten. In dit geval is het beter om de VM naar een server met krachtigere processors te verplaatsen.
U kunt ook proberen de instellingen voor energieverbruik in het server-BIOS te controleren. Veel beheerders schakelen de High Performance-modus in het BIOS in en schakelen daarmee de energiebesparende technologieën C-state en P-state uit. Moderne Intel-processors maken gebruik van Turbo Boost-technologie, die de frequentie van individuele processorkernen verhoogt ten koste van andere kernen. Maar het werkt alleen als energiebesparende technologieën zijn ingeschakeld. Als we ze uitschakelen, kan de processor het stroomverbruik van niet-geladen kernen niet verminderen.
VMware raadt aan om energiebesparende technologieën op servers niet uit te schakelen, maar modi te kiezen die het energiebeheer zoveel mogelijk aan de hypervisor overlaten. In dit geval moet u in de instellingen voor energieverbruik van de hypervisor Hoge prestaties selecteren.
Als u individuele VM's (of VM-kernen) in uw infrastructuur heeft die een verhoogde CPU-frequentie vereisen, kan het correct aanpassen van het energieverbruik hun prestaties aanzienlijk verbeteren.
CPU-gereed
Als de VM-kern (vCPU) de status Gereed heeft, voert deze geen nuttig werk uit. Deze situatie doet zich voor wanneer de hypervisor geen vrije fysieke kern vindt waaraan het vCPU-proces van de virtuele machine kan worden toegewezen.
Hoe analyseren? Als de kernen van een virtuele machine meer dan 10% van de tijd de status Gereed hebben, zult u doorgaans prestatieproblemen opmerken. Simpel gezegd wacht de VM meer dan 10% van de tijd totdat fysieke bronnen beschikbaar komen.
In vCenter kunt u 2 tellers bekijken die verband houden met CPU Ready:
- gereedheid,
- Klaar.
De waarden van beide tellers kunnen zowel voor de gehele VM als voor individuele cores worden bekeken.
Gereedheid toont de waarde onmiddellijk als percentage, maar alleen in realtime (gegevens van het afgelopen uur, meetinterval 20 seconden). Het is beter om deze teller alleen te gebruiken om problemen “op de hielen” te zoeken.
Kant-en-klare tellerwaarden kunnen ook vanuit historisch perspectief worden bekeken. Dit is nuttig voor het vaststellen van patronen en voor een diepere analyse van het probleem. Als een virtuele machine bijvoorbeeld op een bepaald moment prestatieproblemen begint te ondervinden, kunt u de intervallen van de CPU Ready-waarde vergelijken met de totale belasting op de server waarop deze VM draait, en maatregelen nemen om de belasting te verminderen (als DRS mislukt).
Klaar wordt, in tegenstelling tot Gereedheid, niet in percentages weergegeven, maar in milliseconden. Dit is een teller van het sommatietype, dat wil zeggen dat deze laat zien hoe lang de VM-kern tijdens de meetperiode in de status Gereed was. U kunt deze waarde omzetten in een percentage met behulp van een eenvoudige formule:
(CPU gereed sommatiewaarde / (standaard update-interval van diagram in seconden * 1000)) * 100 = CPU gereed %
Voor de VM in de onderstaande grafiek is de piek Ready-waarde voor de gehele virtuele machine bijvoorbeeld als volgt:
Bij het berekenen van het Ready-percentage moet je op twee punten letten:
- De Ready-waarde voor de gehele VM is de som van Ready voor alle kernen.
- Meetinterval. Voor Realtime is dit 20 seconden en op dagelijkse grafieken bijvoorbeeld 300 seconden.
Met actieve probleemoplossing kunnen deze eenvoudige punten gemakkelijk over het hoofd worden gezien en kan kostbare tijd worden verspild aan het oplossen van niet-bestaande problemen.
Laten we Ready berekenen op basis van de gegevens uit de onderstaande grafiek. (324474/(20*1000))*100 = 1622% voor de gehele VM. Als je naar de kernen kijkt, is het niet zo eng: 1622/64 = 25% per kern. In dit geval is het addertje onder het gras vrij eenvoudig te herkennen: de Ready-waarde is onrealistisch. Maar als we het hebben over 10-20% voor de gehele VM met meerdere kernen, dan kan de waarde voor elke kern binnen het normale bereik liggen.
Wat te doen? Een hoge Ready-waarde geeft aan dat de server niet over voldoende processorbronnen beschikt voor de normale werking van virtuele machines. In een dergelijke situatie hoeft u alleen nog maar het overabonnement per processor (vCPU:pCPU) te verminderen. Uiteraard kan dit worden bereikt door de parameters van bestaande VM's te verminderen of door een deel van de VM's naar andere servers te migreren.
Co-stop
Hoe analyseren? Deze teller is eveneens van het type Sommatie en wordt op dezelfde manier als Klaar omgezet naar percentages:
(CPU co-stop optellingswaarde / (standaard update-interval van diagram in seconden * 1000)) * 100 = CPU co-stop%
Hier moet je ook letten op het aantal cores op de VM en het meetinterval.
In de costop-status verricht de kernel geen nuttig werk. Met de juiste selectie van de VM-grootte en normale belasting van de server zou de co-stop-teller bijna nul moeten zijn.
In dit geval is de belasting duidelijk abnormaal :)
Wat te doen? Als er meerdere VM’s met een groot aantal cores op één hypervisor draaien en er sprake is van overabonnement op de CPU, dan kan de co-stopteller oplopen, wat tot problemen met de performance van deze VM’s zal leiden.
Ook zal de co-stop toenemen als de actieve kernen van één VM threads gebruiken op één fysieke serverkern met hyper-treading ingeschakeld. Deze situatie kan zich bijvoorbeeld voordoen als de VM meer cores heeft dan fysiek beschikbaar zijn op de server waarop deze draait, of als de “preferHT”-instelling is ingeschakeld voor de VM. U kunt over deze instelling lezen .
Om problemen met de VM-prestaties als gevolg van hoge co-stop te voorkomen, selecteert u de VM-grootte in overeenstemming met de aanbevelingen van de fabrikant van de software die op deze VM draait en de mogelijkheden van de fysieke server waarop de VM draait.
Voeg geen reservekernen toe; dit kan prestatieproblemen veroorzaken, niet alleen voor de VM zelf, maar ook voor zijn buren op de server.
Andere nuttige CPU-statistieken
lopen – hoeveel tijd (ms) tijdens de meetperiode de vCPU zich in de RUN-status bevond, dat wil zeggen dat hij daadwerkelijk nuttig werk verrichtte.
Idle – hoe lang (ms) tijdens de meetperiode de vCPU in een staat van inactiviteit was. Hoge Idle-waarden zijn geen probleem, de vCPU had gewoon ‘niets te doen’.
Wacht – hoe lang (ms) tijdens de meetperiode de vCPU zich in de wachtstatus bevond. Omdat IDLE in deze teller is opgenomen, duiden hoge Wait-waarden ook niet op een probleem. Maar als Wait IDLE laag is terwijl Wait hoog is, betekent dit dat de VM wachtte tot I/O-bewerkingen waren voltooid, en dit kan op zijn beurt duiden op een probleem met de prestaties van de harde schijf of eventuele virtuele apparaten van de VM.
Maximaal beperkt – hoe lang (ms) tijdens de meetperiode de vCPU zich in de status Gereed bevond vanwege de ingestelde resourcelimiet. Als de prestaties onverklaarbaar laag zijn, is het handig om de waarde van deze teller en de CPU-limiet in de VM-instellingen te controleren. VM's kunnen inderdaad limieten hebben waarvan u zich niet bewust bent. Dit gebeurt bijvoorbeeld wanneer een VM is gekloond vanuit een sjabloon waarop de CPU-limiet is ingesteld.
Wissel wacht – hoe lang tijdens de meetperiode de vCPU heeft gewacht op een bewerking met VMkernel Swap. Als de waarden van deze teller boven nul liggen, heeft de VM zeker prestatieproblemen. We zullen meer over SWAP praten in het artikel over RAM-tellers.
ESXTOP
Als prestatiemeteritems in vCenter goed zijn voor het analyseren van historische gegevens, kan de operationele analyse van het probleem beter worden gedaan in ESXTOP. Hier worden alle waarden in kant-en-klare vorm gepresenteerd (u hoeft niets te vertalen) en de minimale meetperiode is 2 seconden.
Het ESXTOP-scherm voor CPU wordt opgeroepen met de "c"-toets en ziet er als volgt uit:
Voor het gemak kunt u alleen virtuele machineprocessen verlaten door op Shift-V te drukken.
Om statistieken voor individuele VM-kernen te bekijken, drukt u op “e” en voert u de GID in van de gewenste VM (30919 in de onderstaande schermafbeelding):
Ik zal kort de kolommen doornemen die standaard worden weergegeven. Extra kolommen kunnen worden toegevoegd door op "f" te drukken.
NWLD (aantal werelden) – aantal processen in de groep. Om de groep uit te breiden en statistieken voor elk proces te bekijken (bijvoorbeeld voor elke kern in een multi-core VM), drukt u op “e”. Als er meer dan één proces in een groep zit, zijn de metrische waarden voor de groep gelijk aan de som van de metrische waarden voor de individuele processen.
%GEBRUIKT – hoeveel server-CPU-cycli worden gebruikt door een proces of een groep processen.
%LOOP – hoe lang het proces tijdens de meetperiode in de RUN-status was, d.w.z. nuttig werk verricht. Het verschilt van %USED doordat het geen rekening houdt met hyperthreading, frequentieschaling en tijd besteed aan systeemtaken (%SYS).
%SYS – tijd besteed aan systeemtaken, bijvoorbeeld: interruptverwerking, I/O, netwerkbeheer, enz. De waarde kan hoog zijn als de VM een grote I/O heeft.
%OVRLP – hoeveel tijd de fysieke kern waarop het VM-proces draait, besteedt aan taken van andere processen.
Deze statistieken hebben als volgt betrekking op elkaar:
%USED = %RUN + %SYS - %OVRLP.
Normaal gesproken is de statistiek %USED informatiever.
%WACHTEN – hoe lang gedurende de meetperiode het proces in de wachttoestand stond. Schakelt IDLE in.
%INACTIEF – hoe lang tijdens de meetperiode het proces in de IDLE-status was.
%SWPWT – hoe lang tijdens de meetperiode de vCPU heeft gewacht op een bewerking met VMkernel Swap.
%VMWACHT – hoe lang tijdens de meetperiode de vCPU in de wachtstand stond op een gebeurtenis (meestal I/O). Er is geen vergelijkbare teller in vCenter. Hoge waarden duiden op problemen met I/O op de VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Als de VM geen VMkernel Swap gebruikt, is het raadzaam om bij het analyseren van prestatieproblemen naar %VMWAIT te kijken, omdat deze metriek geen rekening houdt met het tijdstip waarop de VM niets deed (%IDLE).
%RDY – hoe lang tijdens de meetperiode het proces in de status Gereed was.
%CSTP – hoe lang gedurende de meetperiode het proces zich in de costop-toestand bevond.
%MLMTD – hoe lang tijdens de meetperiode de vCPU zich in de status Gereed bevond vanwege de ingestelde resourcelimiet.
%WAIT + %RDY + %CSTP + %RUN = 100% – de VM-kern bevindt zich altijd in een van deze vier statussen.
CPU op hypervisor
vCenter heeft ook CPU-prestatietellers voor de hypervisor, maar die zijn niets interessants: ze zijn eenvoudigweg de som van de tellers voor alle VM's op de server.
De handigste manier om de CPU-status op de server te bekijken is op het tabblad Samenvatting:
Zowel voor de server als voor de virtuele machine is er een standaard Alarm:
Wanneer de CPU-belasting van de server hoog is, beginnen de VM's die erop draaien prestatieproblemen te ondervinden.
In ESXTOP worden de CPU-belastingsgegevens van de server bovenaan het scherm weergegeven. Naast de standaard CPU-belasting, die niet erg informatief is voor hypervisors, zijn er nog drie statistieken:
KERNUTIL(%) – het laden van de fysieke serverkern. Deze teller laat zien hoeveel tijd de kern arbeid heeft verricht tijdens de meetperiode.
PCPU-UTIL(%) – als hyperthreading is ingeschakeld, zijn er twee threads (PCPU) per fysieke kern. Deze statistiek laat zien hoe lang het duurde voordat elke thread het werk voltooide.
PCPU GEBRUIKT (%) – hetzelfde als PCPU UTIL(%), maar houdt rekening met frequentieschaling (ofwel het verlagen van de kernfrequentie voor energiebesparende doeleinden, ofwel het verhogen van de kernfrequentie dankzij Turbo Boost-technologie) en hyperthreading.
PCPU_USED% = PCPU_UTIL% * effectieve kernfrequentie / nominale kernfrequentie.
In deze schermafbeelding is voor sommige kernen, als gevolg van Turbo Boost, de USED-waarde groter dan 100%, omdat de kernfrequentie hoger is dan de nominale frequentie.
Een paar woorden over hoe rekening wordt gehouden met hyperthreading. Als processen 100% van de tijd worden uitgevoerd op beide threads van de fysieke kern van de server, terwijl de kern op de nominale frequentie werkt, dan:
- CORE UTIL voor de kern is 100%,
- PCPU UTIL voor beide threads is 100%,
- PCPU GEBRUIKT voor beide threads is 50%.
Als beide threads tijdens de meetperiode niet 100% van de tijd werkten, wordt tijdens de perioden waarin de threads parallel werkten, de voor de kernen GEBRUIKTE PCPU in tweeën gedeeld.
ESXTOP heeft ook een scherm met parameters voor het energieverbruik van de CPU van de server. Hier kunt u zien of de server gebruik maakt van energiebesparende technologieën: C-states en P-states. Opgeroepen met de "p"-toets:
Veelvoorkomende CPU-prestatieproblemen
Ten slotte bespreek ik de typische oorzaken van problemen met VM CPU-prestaties en geef ik korte tips om deze op te lossen:
De kernkloksnelheid is niet voldoende. Als het niet mogelijk is om uw VM te upgraden naar krachtigere cores, kunt u proberen de energie-instellingen te wijzigen om Turbo Boost efficiënter te laten werken.
Onjuiste VM-grootte (te veel/weinig kernen). Als u weinig cores installeert, zal de CPU-belasting op de VM hoog zijn. Als er veel is, neem dan een hoge co-stop.
Grote overinschrijving van CPU op de server. Als de VM een hoge Ready-waarde heeft, verminder dan de CPU-overabonnement.
Onjuiste NUMA-topologie op grote virtuele machines. De NUMA-topologie gezien door de VM (vNUMA) moet overeenkomen met de NUMA-topologie van de server (pNUMA). Diagnostiek en mogelijke oplossingen voor dit probleem worden bijvoorbeeld in het boek geschreven . Als je niet dieper wilt gaan en geen licentiebeperkingen hebt voor het besturingssysteem dat op de VM is geïnstalleerd, maak dan veel virtuele sockets op de VM, één kern tegelijk. Je zult niet veel verliezen :)
Dat is voor mij alles over de CPU. Vragen stellen. In het volgende deel zal ik het hebben over RAM.
Nuttige links
Bron: www.habr.com