Bij het oplossen van problemen met de CPU-prestaties op gevirtualiseerde SQL-servers die op VMware draaien, is een van de eerste dingen die ik doe controleren of de configuratie van de virtuele machine geen factor is die bijdraagt aan het prestatieprobleem. Waar een fysieke server 100% van de beschikbare bronnen voor het besturingssysteem heeft, heeft een virtuele machine dat niet, dus als u vooraf een paar basisitems bekijkt, kunt u het verkeerde probleem oplossen en tijd verspillen. In het verleden heb ik geblogd over het belang van DBA's die alleen-lezen toegang hebben tot Virtual Center for VMware voor het oplossen van basisproblemen met prestatieproblemen. Maar zelfs zonder toegang tot Virtual Center is het nog steeds mogelijk om wat basisinformatie in Windows te achterhalen die kan leiden tot mogelijke problemen op hostniveau die de prestaties beïnvloeden.
Elke virtuele VMware-machine heeft twee prestatiemetergroepen in Windows die worden toegevoegd wanneer de VMware-tools in de gast worden geïnstalleerd; VM-processor en VM-geheugen. Deze prestatiemeteritems zijn een van de eerste dingen waar ik naar kijk als ik met een virtuele machine op VMware werk, omdat ze je een idee geven van de bronnen die de VM van de hypervisor ontvangt. De VM Processor-groep heeft de volgende tellers:
- % processortijd
- Effectieve VM-snelheid in MHz
- Snelheid hostprocessor in MHz
- Limiet in MHz
- Reservering in MHz
- Aandelen
Op een VM-gast die een hoge processor\% processortijd laat zien in Taakbeheer of perfmon, zal het controleren van de VM-processortellers een nauwkeurig overzicht geven van de werkelijke brontoewijzingen die de VM-gast ontvangt. Als de snelheid van de hostprocessor in MHz 3000 is en de gast 8 virtuele CPU's heeft toegewezen, dan is de maximale effectieve snelheid voor de VM 24000 MHz en geeft de teller van de effectieve VM-snelheid in MHz aan of de VM daadwerkelijk de bronnen krijgt van de gastheer. Wanneer dit het geval is, moet u meestal naar de informatie op hostniveau gaan kijken om de oorzaak van het probleem verder vast te stellen. Maar in een recente klantinteractie bleek dit niet het geval te zijn.
De client-VM kwam in dit geval overeen met de hierboven beschreven configuratie en had een maximale effectieve snelheid van 24000 MHz, maar de teller van de effectieve VM-snelheid in MHz bedroeg slechts gemiddeld ongeveer 6900 MHz met de VM Windows Procent Processor-tijd vastgepend op bijna 100%. Toen we net onder de teller van de effectieve VM-snelheid in MHz keken, bleek de oorzaak van het probleem:de limiet in MHz was 7000, wat betekent dat de VM een geconfigureerde limiet voor CPU-gebruik had op 7000 MHz in ESX, dus het werd constant gesmoord door de hypervisor onder laden.
De verklaring hiervoor was dat deze specifieke VM was gebruikt voor testdoeleinden in een proof of concept en oorspronkelijk op een drukke VM-host was geplaatst; de VM-beheerders wilden niet dat een onbekende workload prestatieproblemen veroorzaakte op die host. Dus, om ervoor te zorgen dat het geen negatieve invloed zou hebben op de echte productie-workloads op de host tijdens de POC, was het beperkt tot slechts 7000 MHz CPU of het equivalent van 2 1/3 fysieke cores op de host. Uiteindelijk elimineerde het verwijderen van de VM CPU-limiet in ESX de hoge CPU-problemen in Windows en verdwenen de prestatieproblemen die de client ondervond.
De VM-geheugentellergroep is net zo belangrijk als de VM-processorgroep voor het identificeren van potentiële prestatieproblemen voor SQL Server. De VM-geheugentellergroep bevat de volgende tellers:
- Geheugen actief in MB
- Geheugen ballon in MB
- Geheugenlimiet in MB
- Geheugen toegewezen in MB
- Geheugenoverhead in MB
- Geheugenreservering in MB
- Geheugen gedeeld in MB
- Gedeeld geheugen Opgeslagen in MB
- Geheugenaandelen
- Geheugen verwisseld in MB
- Geheugen gebruikt in MB
Van deze tellers kijk ik specifiek naar de Memory Ballooned in MB en de Memory Swapped in MB, die beide nul zouden moeten zijn voor SQL Server-workloads. De Memory Ballooned in MB-teller geeft aan hoeveel geheugen is teruggewonnen van de gast-VM door het ballonstuurprogramma als gevolg van geheugenoverbelasting op de host, waardoor SQL Server het geheugengebruik vermindert om te reageren op geheugendruk in Windows veroorzaakt door het ballonstuurprogramma opblazen om geheugen weg te nemen van de VM. De Memory Swapped in MB-teller houdt bij hoeveel geheugen door de host-hypervisor naar de schijf is gewisseld vanwege een teveel aan geheugen op de host die niet kon worden opgelost door VM-gasten met de ballonbestuurder te laten ballonvaren. De best practice-gids van VMware voor SQL Server raadt het gebruik van reserveringen aan om te garanderen dat SQL Server om prestatieredenen niet opgeblazen of uitgewisseld wordt, maar veel VM-beheerders aarzelen om statische reserveringen in te stellen omdat dit de omgevingsflexibiliteit vermindert.
Monitoringtools, zoals SentryOne V Sentry, kunnen ook helpen. Overweeg het geval waarin u mogelijk geen directe toegang tot vCenter hebt, maar iemand namens u toezicht kan instellen. Nu kunt u geweldige visualisatie en inzicht krijgen in CPU-, geheugen- en zelfs schijfproblemen - op zowel gast- als hostniveau - en ook alle bijbehorende geschiedenis. Op het onderstaande dashboard ziet u aan de linkerkant hoststatistieken (inclusief CPU-specificaties voor co-stop en gereed-tijd), en gaststatistieken aan de rechterkant:
Om deze en andere functionaliteit van SentryOne uit te proberen, kunt u een gratis proefversie downloaden.
Conclusie
Bij het oplossen van prestatieproblemen op gevirtualiseerde SQL-servers op VMware, is het belangrijk om het probleem vanuit een holistisch standpunt te bekijken in plaats van het probleem op te lossen met slechts beperkte informatie. De VMware-specifieke tellers in Prestatiemeter kunnen een goede manier zijn om snel te controleren of de VM de basisbrontoewijzingen van de host ontvangt, voordat verdere stappen worden ondernomen om het probleem op te lossen.