VMware-CPU-Hot-Plug-vNUMA-Auswirkungen auf SQL Server

Als ESX 5 und Hyper-V in Windows Server 2012 veröffentlicht und die zuvor bestehenden Beschränkungen für VM-Größen geändert wurden, wusste ich fast sofort, dass wir sehen würden, dass mehr große SQL Server-Workloads virtualisiert werden würden. Ich habe im letzten Jahr mit einer Reihe von Kunden zusammengearbeitet, die SQL Server mit 16 bis 32 Kernen aus verschiedenen Gründen virtualisiert haben, von vereinfachten Notfallwiederherstellungsstrategien, die zum Rest des Unternehmens passten, bis hin zu Konsolidierung und niedrigeren Gesamtbetriebskosten auf neuerer Hardware Plattformen. Einer der Gründe für die Skalierbarkeitsänderung mit ESX 5+ war die Einführung von Virtual NUMA (vNUMA) für breite Gäste, die die Größe eines einzelnen Hardware-NUMA-Knotens überschritten. Mit vNUMA wird die Gast-VM so optimiert, dass sie der Hardware-NUMA-Topologie entspricht, sodass das Gastbetriebssystem und alle NUMA-fähigen Anwendungen wie SQL Server, die auf der VM ausgeführt werden, die NUMA-Leistungsoptimierungen so nutzen können, als ob sie es wären läuft auf einem physischen Server.

Innerhalb von VMware ist eine vNUMA-Topologie auf Hardwareversion 8 oder höher verfügbar und wird standardmäßig konfiguriert, wenn die Anzahl der vCPUs für den Gast größer als acht ist. Es ist auch möglich, die vNUMA-Topologie für eine VM mithilfe erweiterter Konfigurationsoptionen manuell zu konfigurieren, was für VMs nützlich sein kann, denen mehr Arbeitsspeicher zugewiesen ist, als ein physischer NUMA-Knoten bereitstellen kann, die aber immer noch acht oder weniger vCPUs verwenden. Die Standardkonfigurationseinstellungen funktionieren größtenteils für die meisten VMs, die ich mir in den letzten Jahren angesehen habe, aber es gibt bestimmte Szenarien, in denen die vNUMA-Standardtopologie nicht ideal ist und die manuelle Konfiguration einige Vorteile bieten kann. Kürzlich habe ich mit einem Client mit einer Reihe von SQL Server-VMs mit 32 vCPUs und 512 GB RAM gearbeitet, um eine Leistungsoptimierung durchzuführen, bei der die vNUMA-Topologie nicht annähernd den Erwartungen entsprach.

Die VM-Hostserver in dieser Umgebung bestanden aus vier E5-4650-Sockelprozessoren mit acht Kernen und 1 TB RAM, die jeweils für eine einzelne SQL Server-VM unter normalen Betriebsbedingungen dediziert waren, aber über verfügbare Kapazität verfügten, um zwei VMs in einem Ausfallszenario aufrechtzuerhalten. Bei diesem Hardware-Layout gibt es vier NUMA-Knoten, einen pro Socket, und die erwartete VM-Konfiguration würde auch 4 vNUMA-Knoten für eine Konfiguration mit 32 vCPUs aufweisen. Was ich jedoch beim Betrachten der DMVs in SQL Server fand, war, dass dies nicht der Fall war:

Abbildung 1 – Falsche vNUMA-Konfiguration

Wie Sie wahrscheinlich im Bild sehen können, stimmt etwas mit der NUMA-Konfiguration auf diesem Server nicht. Es gibt vier Speicherknoten innerhalb von SQLOS und nur einen einzigen CPU-Knoten, dem alle vCPUs zugeordnet sind. Um ganz ehrlich zu sein, hat mich das umgehauen, als ich es sah, weil es gegen alles verstieß, was ich darüber wusste, wie SQLOS die internen Strukturen beim Start der Instanz konfiguriert. Nachdem ich ein wenig in den ErrorLog-Dateien, dem Systemmonitor und dem Windows Task-Manager herumgegraben hatte, lud ich eine Kopie von CoreInfo von SysInternals herunter und warf einen Blick auf das NUMA-Layout, das an Windows gemeldet wurde.

Zuordnung von logischem Prozessor zu NUMA-Knoten:
******************************** NUMA-Knoten 0

Die CoreInfo-Ausgabe bestätigte, dass die VM die 32 vCPUs als 4 verschiedene Sockets darstellt, gruppierte dann aber alle 32 vCPUs in NUMA-Knoten 0. Wenn ich mir die Windows Server 2012-Leistungsindikatoren auf der VM ansehe, konnte ich dies anhand der NUMA-Knotenspeicher-Zählergruppe erkennen Dem Betriebssystem wurden 4 NUMA-Speicherknoten präsentiert, wobei der Speicher gleichmäßig über die Knoten verteilt war. Dies stimmte alles mit dem überein, was ich in SQLOS sah, und ich konnte auch aus den ERRORLOG-Einträgen beim Start erkennen, dass die CPU-Maske für den Knoten alle verfügbaren CPUs in CPU-Knoten 0 maskierte, aber vier Large Page Allocators erstellt wurden, einer für jedem Speicherknoten.

An diesem Punkt war ich mir sicher, dass es etwas mit der VM-Konfiguration zu tun hatte, aber ich konnte nicht erkennen, was genau das Problem war, da ich dieses Verhalten noch nie auf anderen breiten SQL Server-VMs gesehen hatte, die ich Clients auf VMware ESX 5+ unterstützt hatte in der Vergangenheit. Nachdem einige Konfigurationsänderungen an einem verfügbaren Test-VM-Server vorgenommen wurden, korrigierte nur keine davon die vNUMA-Konfiguration, die in der VM angezeigt wurde. Nach einem Anruf beim VMware-Support wurden wir gebeten, die vCPU-Hotplug-Funktion für die Test-VM zu deaktivieren und zu prüfen, ob das Problem dadurch behoben wurde. Bei deaktiviertem Hotplug auf der VM bestätigte die CoreInfo-Ausgabe, dass die vNUMA-Zuordnung der Prozessoren für die VM nun korrekt war:

Zuordnung von logischem Prozessor zu NUMA-Knoten:
********———————— NUMA-Knoten 0
——–********————— - NUMA-Knoten 1
—————-********——– NUMA-Knoten 2
————————******** NUMA-Knoten 3

Dieses Verhalten ist tatsächlich im VMware-KB-Artikel (vNUMA ist deaktiviert, wenn VCPU-Hotplug aktiviert ist) vom Oktober 2013 dokumentiert. Dies war zufällig die erste breite VM für SQL Server, mit der ich gearbeitet hatte, bei der vCPU-Hotplug aktiviert war, und das ist es keine typische Konfiguration, die ich für eine VM mit 32 vCPUs erwarten würde, aber sie war Teil der Standardvorlage, die auf dem Client verwendet wurde, und wirkte sich zufällig auf deren SQL Server aus.

Auswirkungen der Deaktivierung von vNUMA

Es gibt eine Reihe von Auswirkungen, die eine solche Deaktivierung von vNUMA auf eine Arbeitslast haben könnte, aber es gibt zwei spezifische Probleme, die sich speziell bei dieser Art von Konfiguration auf SQL Server auswirken können. Erstens könnte der Server Probleme mit CMEMTHREAD-Warteakkumulationen haben, da einem einzelnen NUMA-Knoten 32 vCPUs zugewiesen sind und die Standardpartitionierung für Speicherobjekte in SQLOS pro NUMA-Knoten erfolgt. Dieses spezifische Problem wurde von Bob Dorr in der CSS-Gruppe bei Microsoft in ihrem Blog-Beitrag SQL Server 2008/2008 R2 auf neueren Computern mit mehr als 8 CPUs, die per NUMA-Knoten angezeigt werden, möglicherweise Ablaufverfolgungskennzeichen 8048 erforderlich dokumentiert. Als Teil der Überprüfung der Wartestatistik Auf der VM mit dem Client stellte ich fest, dass CMEMTHREAD der zweithöchste Wartetyp war, was meiner Erfahrung nach ungewöhnlich ist und mich veranlasste, mir die in Abbildung 1 oben gezeigte SQLOS NUMA-Konfiguration anzusehen. In diesem Fall ist das Trace-Flag nicht die Lösung, das Entfernen des vCPU-Hotplugs aus der VM-Konfiguration behebt das Problem.

Das zweite Problem, das sich speziell auf SQL Server auswirken würde, wenn Sie eine ungepatchte Version verwenden, hängt mit der NUMA-Speicherverwaltung in SQLOS und der Art und Weise zusammen, wie SQLOS Away-Seiten während der anfänglichen Speicherhochlaufphase nach dem Start der Instanz verfolgt und verwaltet. Dieses Verhalten wurde von Bob Dorr im CSS-Blogbeitrag How It Works:SQL Server (NUMA Local, Foreign and Away Memory Blocks) dokumentiert. Wenn SQLOS während des anfänglichen Hochfahrens versucht, eine lokale Speicherzuweisung vorzunehmen, wenn die zurückgegebene Speicheradresse von einem anderen Speicherknoten stammt, wird die Seite im Wesentlichen zur Away-Liste hinzugefügt, und es erfolgt ein weiterer lokaler Speicherzuweisungsversuch, und der Prozess wird wiederholt, bis eine lokale Speicherzuordnung erfolgreich ist oder das Serverspeicherziel erreicht ist. Da drei Viertel des Arbeitsspeichers unserer Instanzen auf NUMA-Knoten ohne Planer vorhanden sind, führt dies zu einer verschlechterten Leistungsbedingung während des anfänglichen Hochfahrens des Arbeitsspeichers für die Instanz. Kürzliche Aktualisierungen haben das Verhalten der Speicherzuweisung während des anfänglichen Hochfahrens dahingehend geändert, dass die lokale Speicherzuweisung nur eine festgelegte Anzahl von Malen versucht wird (die genaue Anzahl ist nicht dokumentiert), bevor der Fremdspeicher zur Fortsetzung der Verarbeitung verwendet wird. Diese Aktualisierungen sind in KB Nr. 2819662, FIX:SQL Server Performance Issues in NUMA Environments dokumentiert.

Zusammenfassung

Für breite VMs, definiert als mit mehr als 8 vCPUs, ist es wünschenswert, dass vNUMA vom Hypervisor an die VM übergeben wird, damit Windows und SQL Server die NUMA-Optimierungen innerhalb ihrer Codebasis nutzen können. Daher sollte für diese breiteren VMs die vCPU-Hotplug-Konfiguration nicht aktiviert sein, da dies nicht mit vNUMA kompatibel ist und bei der Virtualisierung zu einer verminderten Leistung für SQL Server führen kann.