VMWare ESXi Performanceimpact von CPU Hotplug

Vielen wird der Begriff NUMA nur im Entferntesten ein Begriff sein, doch gerade in virtualisierten, High-Performance Infrastrukturen kann eine fehlerhafte Konfiguration jener einen entscheidenden Einfluss haben. Welchen Performance Impact hat das Aktivieren von CPU Hotplug in einer VMWare ESXi? Stellt ESXi dem Gastbetriebssystem die korrekte Anzahl an NUMA Nodes zur Verfügung? Wie erkenne ich auf einem Windows Server ob meine NUMA Nodes korrekt zugewiesen worden sind? Diese Fragen möchte ich in diesem Artikel näher behandeln und somit etwas Licht ins Dunkle bringen.

Was sind NUMA Nodes?

Was NUMA Nodes sind und warum sie auf die Performance des Systems einen nicht zu vernachlässigen Einfluss haben können, habe ich bereits in diesem Artikel beleuchtet. Außerdem erkläre ich dort auch, welche Automatismen VMWare implementiert hat, um eine optimale Verteilung der NUMA Nodes zu gewährleisten. Wer sich also erst mit den Grundsätzen vertraut machen möchte, sollte zuerst dort vorbeischauen.

Windows Server als Praxisbeispiel

Testaufbau

In den nachfolgenden Kapiteln beziehe ich mich, falls nicht anders aufgeführt, immer auf den folgenden Aufbau:

• Server: Dell PowerEdge
• CPUs: 2x Intel CPU 8 Cores
• RAM: 128GB pro CPU (insgesamt 256GB)
• NUMA: 2x NUMA Nodes (jeweils 8 Cores und 128GB RAM)
• Lokalem SSD Storage
• Virtualisiert mittels VMWare ESXi 7.0

Auf dieser Hardware betreiben wir virtuelle Maschinen mit Windows Server 2022 mit unterschiedlichen Hardware-Konfigurationen. Zum Zeitpunkt der Tests wird jeweils immer nur eine VM im aktiven Zustand betrieben, damit die Testergebnisse nicht durch die Last anderer Gastbetriebssysteme verfälscht wird.

Sysinternals Coreinfo

Um die NUMA Nodes direkt auf Windows Server auslesen zu können, verwenden wir das Tools von Sysinternals namens Coreinfo. Dabei handelt es sich um eine lightweight Applikation, die ohne Installation direkt via CLI angesprochen werden kann und die notwendigen Informationen vom System ausliest.

Auswirkungen von CPU Hotplug

Wie in diesem Artikel bereits beschrieben, sollte das Aktivieren von CPU Hotplug einen negativen Impact auf die Bereitstellung der vNUMA Nodes für das Gastbetriebssystem haben. Dies wollen wir nun noch anhand unseres Testaufbaus bestätigen.

CPU Hotplug deaktiviert

Wir starten also eine VM auf dem oben genannten Hypervisor mit folgenden Spezifikationen:

Mittels Coreinfo rufen wir die aus Sicht von Windows konfigurierten Details zur CPU- und NUMA-Verteilung ab und bekommen folgendes Ergebnis:

Da der CPU pro Socket Wert in VMWare auf „1“ gesetzt wurde, stehen der VM aus Sicht von Windows 16 Prozessoren (und nicht zwei Prozessoren mit jeweils 8 Kernen) zur Verfügung. Für diesen Artikel jedoch weit ausschlaggebender sind die zugewiesenen NUMA Nodes. Wie im Testaufbau beschrieben hat das System zwei physische NUMA Nodes, welche dem Gastbetriebssystem auch als zwei vNUMA Nodes bereitgestellt werden. Somit können wir in diesem Fall die optimale Latenz auf Zugriffe zwischen Prozessoren und Arbeitsspeicher gewährleisten.

CPU Hotplug aktiviert

Im nächsten Schritt nehmen wir die gleichen Hardware-Spezifikationen der VM, aktivieren diesmal allerdings das VMWare Feature CPU Hotplug. Somit sieht die virtuelle Maschine wie folgt aus:

Sollte unsere Annahme richtig sein, dürfte Windows Server nun nur noch eine NUMA Node sehen und genau so ist es auch.

Da dem Gastbetriebssystem jetzt nur noch eine vNUMA Node präsentiert wird, wir die VM am Hypervisor jedoch auf zwei physischen NUMA Nodes betreiben, kann Windows Server die Speicherzuweisung nicht mehr optimal treffen. Hierbei kann es also jederzeit passieren, dass Daten im Remote-RAM über den Interconnect-Bus abgelegt werden. Das kann höhere Latenzen und somit eine Verlangsamung des gesamten Systems zur Folge haben.

Somit haben wir bewiesen, dass das Aktivieren von CPU Hotplug eine Auswirkung auf die Bereitstellung der vNUMA Nodes hat. Das gilt natürlich nicht nur für Windows Server sondern grundsätzlich für jedes Gastbetriebssystem auf dem ESXi. Doch wie groß ist der Performanceimpact überhaupt?

Ergänzung

Bevor ich dieser Frage im nächsten Kapitel auf den Grund gehe, möchte ich zu dem Thema noch weitere Informationen ergänzen. Da VMWare ESXi immer die größtmögliche Anzahl an vCPUs in die kleinstmögliche Anzahl an physischen NUMA Nodes packt, gilt der negative Impact vom Aktivieren des CPU Hotplug Features nur, wenn die vCPUs der VM jenen der physischen Cores des NUMA Nodes übersteigt. Mit dem oben genannten Hypervisor bedeutet das also, dass eine VM mit weniger als 8 vCPUs und aktiviertem CPU Hotplug keine Performanceeinbußen befürchten muss. In dieser Konstellation würde VMWare ESXi dem Gast-OS ohnehin nur eine vNUMA Node bereitstellen.

Impact fehlerhafte NUMA Verteilung

Vorwort

Widmen wir uns nun dem Thema, wie groß der Performanceimpact ist, wenn ESXi die vNUMA Nodes nicht korrekt an das Betriebssystem weitergibt. Wichtig sei hier noch zu erwähnen, dass man die nachfolgenden Ergebnisse nicht verallgemeinern kann. Wie groß der Einfluss auf die tatsächliche Workload des Systems ist, wird durch mehrere Faktoren beeinflusst:

• Hardware des Hypervisors
• Gastbetriebssystem
• Applikation
• Intensität der Workloads

Beispielsweise wird man bei einem einfachen Domain Controller, welcher keine performanceintensiven Workloads bearbeiten muss, so gut wie keinen Unterschied feststellen können. Jedoch kann das Thema bei einer High-Performance MSSQL Instanz schon wieder ganz anders aussehen. Die nachfolgenden Ergebnisse dienen also eher als Richtung und sind keinesfalls auf jedes X-beliebige System übertragbar.

Tests

Für alle nachfolgenden Tests gelten die folgenden VM Spezifikationen:

• 16vCPUs
• 200GB RAM
• 200GB System (C:) SSD Disks
• 100GB Data (E:) SSD Disks

Intel Memory Latency Checker

Intel stellt ein Tool namens Intel® Memory Latency Checker bereit, mit dem sich mehrere Tests, darunter auch Latenzchecks auf den Arbeitsspeicher des Hosts, vollziehen lassen. Die aus meiner Sicht beiden aussagekräftigsten Checks sind:

• Idle Memory Latency: Stellt jene Latenz dar, die ein RAM-Zugriff benötigt, wenn der Arbeitsspeicher des Systems praktisch vollständig frei ist und der Prozess, welcher auf den Arbeitsspeicher zugreifen möchte, nicht mit anderen Prozessen konkurrieren muss.
• Local and cross-socket Memory Latencies: Ist die Latenz die ein RAM-Zugriff auf die lokale NUMA Node und auf remote NUMA Nodes benötigt. Bei diesem Test sieht man sehr gut, warum eine korrekte NUMA Node Verteilung für die Performance eines Systems wichtig ist.

Fangen wir mit dem „Idle Memory Latency“ Check an:

Inkorrekte NUMA Node Verteilung (CPU Hotplug aktiv)	Korrekte NUMA Node Verteilung (CPU Hotplug deaktiviert)

Hierbei sehen wir ganz klar, dass der RAM-Zugriff um 25ns (22%) langsamer ist, wenn das Gastbetriebssystem nicht erkennt, welcher RAM-Baustein optimalerweise von welchem CPU Kern bedient werden soll. Bei einem System mit einer inkorrekte NUMA Node Verteilung wird dem Betriebssystem nur eine vNUMA Node bereitgestellt und daher kann es jederzeit passieren, dass die CPU auf den von sich aus „entfernten“ Arbeitsspeicher zugreifen muss. Da der Zugriff dabei über den langsameren Interconnect-Bus passiert, sind die Latenzen entsprechend höher.

Um diese These weiter zu verifizieren, starten wir nun den „Local and cross-socket Memory Latencies“ Check:

Inkorrekte NUMA Node Verteilung (CPU Hotplug aktiv)	Korrekte NUMA Node Verteilung (CPU Hotplug deaktiviert)

Im Grunde ist dieser Check dem vorhergehenden sehr ähnlich nur sehen wir jetzt, wie das System mit dem Arbeitsspeicherzugriff umgeht, wenn es vom Hypervisor die korrekten NUMA Nodes zugewiesen bekommt.

PassMark PerformanceTest

PassMark ist ein weit verbreitetes Benchmarking Tool für Clients, als auch Server. Für unsere Zwecke verwenden wir den RAM-Benchmark. Bei den Tests wurden pro VM-Konfiguration (NUMA AWARE / NUMA UNAWARE) insgesamt 20 Iterationen durchgeführt und der daraus resultierende Mittelwert berechnet. Schauen wir uns einmal die Ergebnisse für den Arbeitsspeicher an:

*niedriger ist besser

Der Host mit korrekter NUMA Node Verteilung schneidet nahezu in jedem Test (ausgenommen Memory Read Cached) besser ab, als jener mit aktiviertem CPU Hotplug und somit einer fehlerhaften NUMA Node Konfiguration.

HammerDB MSSQL Benchmark

Im dritten Test schauen wir uns die Leistungsunterschiede auf einer MSSQL 2019 Enterprise Instanz an. Um entsprechende Last auf dem System zu generieren, verwenden wir das Tool HammerDB. Mittels HammerDB erstellen wir uns im ersten Schritt eine Dummy-Datenbank mit einer Gesamtgröße von 50GB. Damit Variablen wie beispielsweise Disk I/Os so gut als möglich keine Relevanz haben, haben wir die gesamte Datenbank in den Arbeitsspeicher des Hosts laden lassen. Somit sollten Read-Zugriffe größtenteils zwischen CPU und Arbeitsspeicher stattfinden. Der Benchmark selbst wurde mit der Autopilot Funktion und 100 virtuellen Benutzern in insgesamt 10 Iterationen ausgeführt. Das Benchmark Monitoring wurde mittels SQL-Server-First-Responder-Kit aufgezeichnet.

Zum einem sieht man anhand des Tests, dass die Zeit, in der der MSSQL auf andere Prozesse warten muss um knapp 18% höher, als auch die insgesamt verarbeiteten Batch Requests innerhalb der gleichen Zeitspanne um 8% geringer ist.

Fazit

Ich denke mit den oben angeführten Tests lässt sich relativ eindrucksvoll beweisen, dass CPU Hotplug durchaus einen Einfluss auf die Performance des Gastbetriebssystems haben kann. Ich möchte an dieser Stelle noch einmal erwähnen, dass das alles Benchmark Tests unter „Laborbedingungen“ sind und der Impact auf unterschiedlicher Hardware oder anderen Applikationen ganz anders aussehen kann. Auch habe ich die Testergebnisse gekürzt und auf das Wichtigste beschränkt, um den Artikel nicht unnötig in die Länge zu ziehen.

Als Faustregel lassen sich aber meiner Meinung nach folgende Schlüsse ziehen:

• CPU Hotplug hat einen Einfluss auf die NUMA Node Konfiguration des Hosts
• CPU Hotplug sollte immer deaktiviert werden, wenn die vCPUs der VM jenen der physischen Cores einer NUMA Node übersteigen
• Besitzt die VM weniger vCPUs als der NUMA Node physische Cores, hat CPU Hotplug keinen Einfluss
• vNUMA Nodes werden von VMWare korrekt dargestellt und können durchaus Einfluss auf die Performance des Gastbetriebssystems haben