Bei der Behebung von CPU-Leistungsproblemen auf virtualisierten SQL-Servern, die auf VMware ausgeführt werden, vergewissere ich mich als Erstes, dass die Konfiguration der virtuellen Maschine nicht zum Leistungsproblem beiträgt. Wo ein physischer Server 100 % der verfügbaren Ressourcen für das Betriebssystem reserviert hat, ist dies bei einer virtuellen Maschine nicht der Fall. Wenn Sie sich also im Voraus ein paar grundlegende Dinge ansehen, vermeiden Sie die Fehlersuche und Zeitverschwendung. In der Vergangenheit habe ich darüber gebloggt, wie wichtig es ist, dass DBAs schreibgeschützten Zugriff auf Virtual Center for VMware für die grundlegende Fehlerbehebung von Leistungsproblemen haben. Aber auch ohne Zugriff auf Virtual Center ist es immer noch möglich, einige grundlegende Informationen innerhalb von Windows herauszufinden, die zu potenziellen Problemen auf Hostebene führen können, die die Leistung beeinträchtigen.
Jede virtuelle VMware-Maschine hat zwei Leistungsindikatorgruppen in Windows, die hinzugefügt werden, wenn die VMware-Tools auf dem Gast installiert werden; VM-Prozessor und VM-Speicher. Diese Leistungsindikatoren sind eines der ersten Dinge, die ich mir anschaue, wenn ich mit einer virtuellen Maschine auf VMware arbeite, weil sie Ihnen einen Überblick darüber geben, welche Ressourcen die VM vom Hypervisor erhält. Die VM-Prozessorgruppe hat die folgenden Zähler:
- % Prozessorzeit
- Effektive VM-Geschwindigkeit in MHz
- Host-Prozessorgeschwindigkeit in MHz
- Limit in MHz
- Reservierung in MHz
- Anteile
Auf einem VM-Gast, der im Task-Manager oder perfmon eine hohe Prozessor-\%-Prozessorzeit anzeigt, liefert die Überprüfung der VM-Prozessorzähler einen genauen Überblick über die tatsächlichen Ressourcenzuweisungen, die der VM-Gast erhält. Wenn die Host-Prozessorgeschwindigkeit in MHz 3000 beträgt und dem Gast 8 virtuelle CPUs zugewiesen sind, beträgt die maximale effektive Geschwindigkeit für die VM 24000 MHz und der Zähler „Effektive VM-Geschwindigkeit in MHz“ gibt an, ob die VM tatsächlich die Ressourcen bezieht der Wirt. Wenn dies der Fall ist, müssen Sie normalerweise mit den Informationen auf Hostebene beginnen, um die Ursache des Problems weiter zu diagnostizieren. Bei einem kürzlich durchgeführten Kundengespräch stellte sich jedoch heraus, dass dies nicht der Fall war.
Die Client-VM stimmte in diesem Fall mit der oben beschriebenen Konfiguration überein und hatte eine maximale effektive Geschwindigkeit von 24.000 MHz, aber der Zähler für die effektive VM-Geschwindigkeit in MHz lag im Durchschnitt nur bei etwa 6.900 MHz, wobei die VM-Windows-Prozessorzeit in Prozent auf fast 100 % festgelegt war. Ein Blick direkt unter den Zähler „Effektive VM-Geschwindigkeit in MHz“ offenbarte die Ursache des Problems:Das Limit in MHz war 7000, was bedeutet, dass die VM eine konfigurierte Obergrenze der CPU-Auslastung bei 7000 MHz in ESX hatte, sodass sie durch den darunter liegenden Hypervisor ständig gedrosselt wurde Belastung.
Die Erklärung dafür war, dass diese spezielle VM zu Testzwecken in einem Proof of Concept verwendet wurde und sich ursprünglich auf einem ausgelasteten VM-Host befand; Die VM-Administratoren wollten nicht, dass eine unbekannte Arbeitslast Leistungsprobleme auf diesem Host verursacht. Um sicherzustellen, dass die realen Produktions-Workloads auf dem Host während des POC nicht negativ beeinflusst werden, wurde es auf nur 7000 MHz CPU oder das Äquivalent von 2 1/3 physischen Kernen auf dem Host beschränkt. Letztendlich beseitigte das Entfernen des VM-CPU-Limits in ESX die hohen CPU-Probleme in Windows, und die Leistungsprobleme, die der Client hatte, verschwanden.
Die Leistungsindikatorengruppe „VM-Arbeitsspeicher“ ist genauso wichtig wie die Gruppe „VM-Prozessor“, um potenzielle Leistungsprobleme für SQL Server zu identifizieren. Die VM-Arbeitsspeicher-Leistungsindikatorgruppe enthält die folgenden Leistungsindikatoren:
- Aktiver Speicher in MB
- Aufgeblähter Arbeitsspeicher in MB
- Speicherlimit in MB
- Zugeordneter Arbeitsspeicher in MB
- Arbeitsspeicher-Overhead in MB
- Speicherreservierung in MB
- Freigegebener Arbeitsspeicher in MB
- Gemeinsamer Arbeitsspeicher gespeichert in MB
- Speicheranteile
- Ausgetauschter Arbeitsspeicher in MB
- Verwendeter Speicher in MB
Von diesen Leistungsindikatoren schaue ich mir speziell Memory Ballooned in MB und Memory Swapped in MB an, die beide für SQL Server-Workloads Null sein sollten. Der Leistungsindikator „Memory Ballooned in MB“ gibt an, wie viel Arbeitsspeicher von der Gast-VM durch den Balloon-Treiber aufgrund einer Speicherüberlastung auf dem Host zurückgefordert wurde, was dazu führt, dass SQL Server die Speichernutzung reduziert, um auf den durch den Balloon-Treiber verursachten Speicherdruck in Windows zu reagieren Aufblähen, um der VM Speicher wegzunehmen. Der Zähler Ausgelagerter Arbeitsspeicher in MB verfolgt, wie viel Arbeitsspeicher vom Host-Hypervisor aufgrund von Arbeitsspeicher-Overcommit auf dem Host, der nicht durch Ballooning von VM-Gästen mit dem Balloon-Treiber behoben werden konnte, auf die Festplatte ausgelagert wurde. Der Best-Practice-Leitfaden von VMware für SQL Server empfiehlt die Verwendung von Reservierungen, um sicherzustellen, dass SQL Server aus Leistungsgründen nicht aufgebläht oder ausgelagert wird, aber viele VM-Administratoren zögern, statische Reservierungen festzulegen, da dies die Flexibilität der Umgebung verringert.
Überwachungstools wie SentryOne V Sentry können ebenfalls hilfreich sein. Stellen Sie sich den Fall vor, in dem Sie möglicherweise keinen direkten Zugriff auf vCenter haben, aber jemand in Ihrem Namen die Überwachung dafür einrichten kann. Jetzt können Sie großartige Visualisierungen und Einblicke in CPU-, Arbeitsspeicher- und sogar Festplattenprobleme erhalten – sowohl auf Gast- als auch auf Hostebene – und auch den gesamten damit verbundenen Verlauf. Auf dem Dashboard unten sehen Sie links Host-Metriken (einschließlich CPU-Aufschlüsselung für Co-Stop und Bereitschaftszeit) und Gast-Metriken rechts:
Um diese und andere Funktionen von SentryOne auszuprobieren, können Sie eine kostenlose Testversion herunterladen.
Schlussfolgerung
Bei der Behebung von Leistungsproblemen auf virtualisierten SQL-Servern auf VMware ist es wichtig, das Problem von einem ganzheitlichen Standpunkt aus zu betrachten, anstatt eine reflexartige Fehlerbehebung mit nur begrenzten Informationen durchzuführen. Die VMware-spezifischen Zähler in Performance Monitor können eine großartige Möglichkeit sein, um schnell zu überprüfen, ob die VM die grundlegenden Ressourcenzuweisungen vom Host erhält, bevor weitere Schritte zur Fehlerbehebung unternommen werden.
