NUMA-BIOS-Einstellungen: Server-Optimierung Schritt für Schritt
Node Interleaving aktiviert: Das Betriebssystem sieht einen gleichförmigen Speicherbereich. Die physische Topologie aus CPU-Sockeln, Speicherkanälen und lokalen Speichercontrollern wird jedoch verdeckt.
Für VMware ESXi, SQL Server und vergleichbare Workloads ist das meist die falsche Konfiguration.
Moderne Xeon- und EPYC-Systeme erreichen ihre Speicherkapazität und ihren Durchsatz über mehrere Speicherkanäle pro Prozessor. Acht Kanäle pro CPU sind bei aktuellen Plattformen üblich. Entscheidend ist nicht nur die installierte DIMM-Menge. Entscheidend ist, welcher Kern auf welchen Speichercontroller zugreift. NUMA-BIOS-Einstellungen steuern genau diese Zuordnung.
Wer NUMA-Knoten im BIOS konfigurieren will, muss drei Ebenen getrennt bewerten:
- die physische Topologie aus Sockeln, Dies, Speichercontrollern und DIMMs,
- die vom BIOS erzeugte NUMA-Topologie,
- die Fähigkeit von Hypervisor, Betriebssystem und Anwendung, lokale Ressourcen zu nutzen.
Erst wenn diese Ebenen zueinander passen, sinken unnötige Remote-Zugriffe. Der Durchsatz bleibt berechenbar. Die Speicherlatenz wird nicht durch vermeidbare Fabric- oder Sockelübertritte erhöht.
Node Interleaving abschalten und NUMA sichtbar machen
Node Interleaving verteilt Speicheradressen über mehrere Prozessorknoten. Das vereinfacht die Sicht des Betriebssystems: Aus mehreren lokalen Speicherbereichen entsteht ein einheitlicher Adressraum. Diese Vereinfachung kostet Lokalisierung.
Bei deaktiviertem Interleaving erkennt das Betriebssystem die NUMA-Domänen. Ein Prozess kann dann bevorzugt auf Kerne und Speicher desselben Knotens gelegt werden. Das ist die Voraussetzung für belastbare CPU-Affinität, virtuelle NUMA-Topologien und speicherlokale Datenbankpuffer.
NUMA ist kein Spezialmodus. NUMA ist die reale Hardwaretopologie. Node Interleaving blendet sie aus.
Die BIOS-Menübezeichnung variiert nach Hersteller. Typische Pfade liegen unter Advanced, Processor Configuration, Memory Configuration oder Performance. Die Logik bleibt gleich:
1. Node Interleaving deaktivieren.
Die Option kann als „Disabled“, „NUMA Enabled“ oder als direkte Interleaving-Einstellung erscheinen. Nach der Änderung muss das Betriebssystem mehrere NUMA-Knoten erkennen.
Aktive Adressverschachtelung setzt gleiche Speicherkapazitäten auf allen beteiligten Prozessorknoten voraus. Ungleiche Bestückung kann Interleaving verhindern oder zu einer unklaren Topologie führen. Auch ohne Interleaving erzeugen asymmetrisch belegte Speicherkanäle ungleichmäßigen Durchsatz.
3. Betriebssystemtopologie validieren.
Unter Linux zeigt lscpu die Anzahl der NUMA-Knoten sowie CPU-Zuordnungen. numactl --hardware ergänzt Speichergrößen und Distanzwerte. Unter Windows liefern Task-Manager, Leistungsüberwachung und PowerShell die Gruppen- und NUMA-Zuordnung. Der Hypervisor muss dieselbe Struktur plausibel abbilden.
4. Erst dann Anwendung und VM bewerten.
Ein Neustart mit aktiviertem NUMA verbessert keine Software, die Threads und Speicher beliebig über alle Knoten verteilt. Die BIOS-Konfiguration liefert die Topologie. Der Scheduler muss sie verwenden.
Node Interleaving hat seinen Platz bei Altanwendungen, die NUMA nicht sauber erkennen, oder bei Lasten mit geringer Speicherintensität und schlechter Thread-Steuerung. Das ist eine Kompatibilitätsentscheidung. Es ist keine allgemeine Performance-Optimierung.
Für virtualisierte Umgebungen und Datenbanken gilt die Gegenrichtung: NUMA im BIOS aktiv lassen. VMware ESXi und SQL Server können ihre Ressourcenverwaltung nur auf eine sichtbare Topologie stützen. Wird die Topologie im Firmware-Layer vereinheitlicht, fehlt diese Grundlage.
AMD EPYC: NPS definiert die Größe der Speicherlokalität
Bei AMD EPYC wird die NUMA-Aufteilung im BIOS über NUMA Nodes Per Socket, kurz NPS, gesteuert. Die Einstellung teilt einen physischen Sockel in logische NUMA-Domänen auf. Damit ändern sich die Beziehungen zwischen CPU-Kernen, Last-Level-Cache, I/O und lokal zugeordnetem Speicher.
Die verfügbaren Modi sind NPS0, NPS1, NPS2 und NPS4. Nicht jede Plattform stellt jede Option in identischer Form bereit. Die Benennung und die unterstützten Modi hängen von EPYC-Generation, Serverplattform und Firmwarestand ab.
| Einstellung | Sicht des Betriebssystems | Primäre Wirkung | Typische Einordnung |
|---|---|---|---|
| NPS0 | stark zusammengefasste Topologie | hohe Abstraktion, geringe NUMA-Sichtbarkeit | Spezial- und Kompatibilitätsszenarien |
| NPS1 | ein NUMA-Knoten je Sockel | einfache, sockelbasierte Zuordnung | VMs mit moderater Kerngröße, allgemeine Serverlast |
| NPS2 | zwei NUMA-Knoten je Sockel | kleinere lokale Speicherbereiche | Workloads mit kontrollierter CPU- und RAM-Affinität |
| NPS4 | vier NUMA-Knoten je Sockel | maximale Granularität innerhalb des Sockels | Datenbanken, HPC und spezialisierte Lasten mit sauberer Bindung |
NPS1 ist die robuste Ausgangskonfiguration für viele virtualisierte Systeme. Das Betriebssystem sieht bei einem Dual-Socket-Server zwei NUMA-Knoten. Diese Abbildung ist leicht zu verstehen und lässt sich bei VM-Größen, die innerhalb eines Sockels bleiben, gut nutzen.
NPS2 und NPS4 verkleinern die einzelne NUMA-Domäne. Dadurch kann die Lokalität innerhalb eines Sockels steigen. Gleichzeitig steigt die Zahl der Grenzen, die Scheduler und Anwendungen beachten müssen. Eine große virtuelle Maschine, deren vCPUs und Arbeitsspeicher mehrere dieser kleinen Domänen überschreiten, profitiert nicht automatisch. Sie kann zusätzliche Remote-Zugriffe erzeugen.
Der Fehler liegt oft in einer falschen Wenn-Dann-Kette:
- Wenn NPS4 mehr NUMA-Knoten erzeugt, dann sinkt die Latenz nicht zwangsläufig für jede Last.
- Wenn die VM größer ist als eine lokale NPS4-Domäne, dann muss der Hypervisor vNUMA sinnvoll aufteilen.
- Wenn die Datenbank Speicher außerhalb ihres bevorzugten Knotens allokiert, dann steigt die effektive Zugriffszeit trotz hoher Kernzahl.
- Wenn DIMMs nicht symmetrisch über die Speicherkanäle verteilt sind, dann kann keine NPS-Einstellung den fehlenden Kanalparallelismus ersetzen.
Die Wahl zwischen NPS1, NPS2 und NPS4 ist daher eine Kapazitäts- und Platzierungsentscheidung. Sie beginnt mit der größten produktiven Einheit: VM, Datenbankinstanz, In-Memory-Cache oder Rechenprozess. Deren CPU- und RAM-Bedarf muss gegen die Größe einer lokalen NUMA-Domäne gelegt werden.
Ein Server mit vielen kleinen VMs verlangt eine andere NPS-Strategie als ein System mit wenigen großen SQL-Server-Instanzen. In der ersten Gruppe sind klare Sockelgrenzen und ein berechenbarer Hypervisor-Scheduler oft vorteilhaft. In der zweiten Gruppe können kleinere Domänen sinnvoll sein, wenn vNUMA, CPU-Pinning und Speicherreservierung konsequent umgesetzt werden.
Intel Xeon: Sub-NUMA Clustering reduziert lokale Wege
Intel Xeon nutzt für eine feinere Topologie Sub-NUMA Clustering oder SNC. Der Mechanismus unterteilt Kerne und Last-Level-Cache in getrennte Cluster. Das Betriebssystem sieht diese Cluster als eigenständige NUMA-Knoten, etwa als SNC-2 oder SNC-4.
SNC verschiebt nicht einfach eine BIOS-Markierung. Es verändert, wie die lokale Zuordnung zwischen Rechenkernen, LLC-Bereichen und Speicherzugriffen organisiert wird. Der Nutzen entsteht bei Workloads, die ihre Threads, Datenbereiche und Affinitäten kontrolliert führen können.
SNC-2 erzeugt zwei Cluster pro Sockel. SNC-4 erhöht die Granularität weiter. Mit jedem zusätzlichen Cluster wird der lokale Bereich kleiner. Das reduziert potenziell lokale Zugriffswege. Gleichzeitig wächst die Wahrscheinlichkeit, dass schlecht platzierte Threads über Clustergrenzen arbeiten.
Kleinere NUMA-Domänen reduzieren nicht pauschal die Latenz. Sie reduzieren nur die Latenz lokaler Zugriffe.
Für Intel-Xeon-NUMA-BIOS-Konfigurationen ist die Reihenfolge klar:
1. Node Interleaving deaktivieren.
2. Die Standardtopologie nach dem Neustart dokumentieren.
3. SNC-2 aktivieren und dieselben Lasten erneut messen.
4. SNC-4 nur prüfen, wenn die Anwendung Clustergrenzen tatsächlich respektiert.
5. UMA-Based Clustering nicht parallel erzwingen.
Wird SNC in der Intel-Firmware aktiviert, deaktiviert das BIOS das UMA-Based Clustering automatisch. Das ist konsistent: Beide Einstellungen verfolgen unterschiedliche Topologieziele. Ein manuelles Gegensteuern über mehrere, überlappende Performance-Optionen erzeugt keine zusätzliche Optimierung.
SNC ist geeignet, wenn die Anwendung NUMA-fähig ist und die Arbeitslast eine stabile Kern- und Speicherbindung besitzt. Dazu gehören bestimmte Datenbank-Engines, analytische Lasten, wissenschaftliche Berechnungen und spezialisierte In-Memory-Verarbeitung. Für ungerichtete Mischlasten kann die feinere Aufteilung dagegen mehr Planungsaufwand erzeugen als sie an Latenz einspart.
Die Messung darf nicht bei einem synthetischen Speichertest enden. Ein hoher sequenzieller Durchsatz beantwortet nicht die Frage, ob die Anwendung lokal allokiert. Relevanter sind:
- Latenz und Durchsatz unter realer Parallelität,
- Anteil der Remote-Speicherzugriffe,
- CPU-Auslastung je NUMA-Knoten,
- Cache-Miss-Raten,
- Antwortzeiten der Datenbank oder Anwendung,
- Scheduler-Migrationen zwischen Knoten.
DIMM-Bestückung bestimmt die erreichbare Topologie
NUMA ist eine Eigenschaft des Gesamtsystems. CPU-Auswahl allein reicht nicht. Ein Prozessor mit acht Speicherkanälen erreicht seine vorgesehene Bandbreite nur, wenn die DIMM-Bestückung diese Kanäle gleichmäßig nutzt.
Die zentrale Regel lautet: Zuerst pro Sockel symmetrisch bestücken, dann pro Kanal symmetrisch erweitern. Unterschiedliche DIMM-Kapazitäten, einzelne unbesetzte Kanäle oder abweichende Bestückungsreihenfolgen verschieben den Flaschenhals in die Speicherarchitektur.
Bei Mehrsockel-Systemen muss die Kapazität nicht nur insgesamt gleich aussehen. Sie muss für die gewünschte NUMA-Topologie gleichmäßig verteilt sein. Zwei Sockel mit jeweils 512 GB sind nicht automatisch symmetrisch, wenn der eine Sockel mit acht DIMMs und der andere mit vier DIMMs arbeitet. Die Gesamtkapazität stimmt. Kanalbelegung, Bandbreite und lokale Kapazitätsverteilung stimmen nicht.
Vor einer NPS- oder SNC-Änderung sind diese Daten zu erfassen:
- Prozessoranzahl und exakte CPU-Generation,
- DIMM-Anzahl, Kapazität, Rank-Aufbau und Geschwindigkeit,
- Belegung pro Speicherkanal und pro Sockel,
- aktuelle BIOS- und BMC-Firmware,
- erkannte NUMA-Knoten im Betriebssystem,
- maximale CPU- und RAM-Größe der produktiven VMs,
- Speicherallokationsmodell der Datenbank oder Anwendung.
Firmwarestände gehören in diese Prüfung. Serverhersteller ergänzen und korrigieren Topologieoptionen über BIOS-Updates. Ein Menüpunkt kann sich nach einem Update umbenennen, neue NPS- oder SNC-Modi können sichtbar werden, und Default-Werte können sich ändern. Die Konfiguration muss deshalb mit exportierten BIOS-Profilen oder einer dokumentierten Baseline abgesichert werden.
Eine häufige Fehlkonfiguration entsteht nach Speichererweiterungen. Zusätzliche DIMMs werden dort eingesetzt, wo Slots frei sind. Das System bootet. Die Gesamtkapazität steigt. Danach zeigt sich unter Last ein ungleichmäßiger Durchsatz zwischen NUMA-Knoten. Das ist kein Scheduler-Problem, sondern eine physische Asymmetrie.
Virtualisierung und Datenbanken: vNUMA nicht durch BIOS-Uniformität ersetzen
Ein Hypervisor plant virtuelle Maschinen auf physische Kerne und Speicherbereiche. Große VMs überschreiten dabei schnell die Grenzen eines einzelnen NUMA-Knotens. vNUMA soll diese Tatsache in die Gastumgebung übertragen.
Wird der physische Server durch Node Interleaving als UMA-System dargestellt, kann der Hypervisor die tatsächlichen Grenzen nicht mehr präzise abbilden. Die Gast-VM erkennt dann eine vereinfachte Welt. Die Speicherzugriffe laufen weiterhin über reale Interconnects und Speichercontroller. Nur die Planungsinformation fehlt.
Bei großen VMs sind drei Werte miteinander abzugleichen:
1. Kerne pro physischem NUMA-Knoten.
Die vCPU-Zahl einer VM sollte nicht ohne Not über diese Grenze wachsen. Überschreitet sie die Grenze, muss die vNUMA-Aufteilung nachvollziehbar sein.
2. Lokaler Speicher pro NUMA-Knoten.
Die reservierte VM-Kapazität muss zur lokalen DIMM-Kapazität passen. Hohe RAM-Reservierungen in einer zu kleinen Domäne erzwingen Remote-Speicher.
3. Anwendungsinternes Parallelitätsmodell.
SQL Server, Java-VMs, Analyse-Engines und In-Memory-Dienste besitzen eigene Thread-Pools und Speicherallokatoren. Diese Parameter müssen zur vNUMA-Struktur passen.
SQL Server und vergleichbare Datenbanklasten profitieren nicht von einer BIOS-Konfiguration, die NUMA unsichtbar macht. Sie benötigen eine stabile Sicht auf CPU- und Speichergruppen. Der Datenbankadministrator kann dann MAXDOP, Worker-Verteilung, Speicherlimits und Prozessaffinitäten fundiert einstellen. Ohne diese Topologie bleibt nur die Reaktion auf Symptome: schwankende Laufzeiten, ungleichmäßige CPU-Last oder unerklärlich steigende Speicherlatenz.
Für kleinere VMs ist Überkonfiguration ebenfalls ein Risiko. Eine fein segmentierte NPS4- oder SNC-4-Topologie kann für eine Maschine mit wenigen vCPUs keinen messbaren Vorteil bringen. Sie vergrößert jedoch die Anzahl der Platzierungsgrenzen im Host. Die präziseste Einstellung ist nicht automatisch die effizienteste Einstellung.
HPE-Systeme: Clustered und Flat richtig einordnen
HPE führt für bestimmte Server die BIOS-Option NUMA Group Size Optimization. Sie stellt unter anderem die Modi Clustered und Flat bereit.
Clustered orientiert die Systemdarstellung an NUMA-Grenzen. Der Modus ist für Betriebssysteme und Anwendungen vorgesehen, die NUMA-Strukturen erkennen und verwalten können. Das entspricht dem Standardziel moderner Serverkonfigurationen: lokale Ressourcen sichtbar machen und ihre Nutzung ermöglichen.
Flat fasst die Darstellung stärker zusammen. Dieser Modus richtet sich an Anwendungen, die mit der granularen NUMA-Topologie nicht umgehen können oder für die eine vereinfachte Sicht erforderlich ist. Flat ist damit keine universelle Leistungsstufe. Es ist eine Kompatibilitätsoption.
Die Zuordnung ist eindeutig:
| Lastprofil | Sinnvolle Topologie | Begründung |
|---|---|---|
| VMware ESXi mit großen VMs | NUMA sichtbar, Clustered | vNUMA und Host-Scheduling benötigen physische Knoteninformationen |
| SQL Server, Oracle, In-Memory-Datenbanken | NUMA sichtbar, Clustered | lokale Speicherallokation und CPU-Gruppen bleiben steuerbar |
| HPC und technisch deterministische Rechenlast | NPS/SNC nach Messung, Clustered | Affinitäten können auf kleine lokale Domänen abgestimmt werden |
| Alte oder NUMA-unfähige Spezialsoftware | Flat oder Interleaving nach Kompatibilitätstest | vereinfachte Speichersicht kann funktional erforderlich sein |
| Allgemeine Mischlast ohne Affinitätsmodell | NPS1 oder SNC-Standard prüfen | geringe Komplexität, klare Sockelgrenzen |
Der Modus muss mit der tatsächlich installierten Software begründet werden. „Flat, weil einfacher“ ist kein Performance-Argument. „Clustered, weil moderner“ ebenfalls nicht. Entscheidend ist die Fähigkeit des Workloads, mehrere NUMA-Knoten korrekt zu nutzen.
Nach der BIOS-Änderung messen, nicht vermuten
Jede Änderung von NPS, SNC, Node Interleaving oder Group Size Optimization verändert die Ressourcensicht des gesamten Servers. Deshalb darf sie nicht isoliert in einem Wartungsfenster gesetzt und anschließend als abgeschlossen betrachtet werden.
Der belastbare Ablauf besteht aus einer Baseline, einer einzelnen Änderung und einem Vergleich unter identischer Last. Gleichzeitig geänderte DIMM-Bestückung, BIOS-Version, Hypervisor-Patch und NUMA-Modus machen Ergebnisse wertlos. Die Ursache bleibt nicht trennbar.
Für eine brauchbare Messreihe reichen drei Stufen:
1. Topologie erfassen.
NUMA-Knoten, CPUs je Knoten, lokaler Speicher und VM-Platzierung dokumentieren.
2. Workload stabil reproduzieren.
Datenbankabfrage, VM-Dichte, Batch-Verarbeitung oder KI-Inferenz müssen mit gleicher Parallelität und gleicher Datenbasis laufen.
3. Anwendungsmetriken priorisieren.
Transaktionen pro Sekunde, Perzentil-Latenzen, Job-Laufzeiten und Remote-Speicheranteile haben Vorrang vor einzelnen synthetischen Bandbreitenwerten.
Absolute Latenzwerte in Nanosekunden lassen sich nicht allgemein aus einer BIOS-Option ableiten. Sie hängen von Prozessorserie, DIMM-Takt, Rank-Konfiguration, Kanalbelegung, Firmware und Lastprofil ab. Eine Konfiguration ist erst dann besser, wenn sie für den konkreten Dienst nachweisbar bessere Antwortzeiten oder höheren stabilen Durchsatz liefert.
Konfigurationsmatrix für den Betrieb
Die folgende Tabelle fasst die BIOS-Entscheidungen zusammen. Sie ersetzt keinen Lasttest. Sie verhindert jedoch die häufigsten Zielkonflikte zwischen Firmware, Speicherbestückung und Scheduler.
| Parameter | Empfohlene Einstellung für NUMA-fähige Serverlasten | Wirkung | Prüfpunkt nach Neustart |
|---|---|---|---|
| Node Interleaving | Deaktiviert | physische NUMA-Knoten bleiben sichtbar | Knotenanzahl und Speicher je Knoten im Betriebssystem |
| AMD EPYC NPS | NPS1 als Baseline; NPS2/NPS4 nach Workload-Messung | definiert NUMA-Domänen pro Sockel | vCPU- und RAM-Größe gegen lokale Domäne prüfen |
| Intel Xeon SNC | SNC-2 als kontrollierter Test; SNC-4 nur bei sauberer Affinität | unterteilt Kerne und LLC in Cluster | Remote-Zugriffe, Cache-Miss-Raten, Anwendungslatenz |
| UMA-Based Clustering bei SNC | nicht zusätzlich erzwingen | BIOS deaktiviert UMA-Based Clustering bei aktivem SNC | wirksame BIOS-Konfiguration dokumentieren |
| HPE NUMA Group Size Optimization | Clustered für NUMA-fähige Anwendungen | orientiert an NUMA-Grenzen | Topologie im Hypervisor und Gast validieren |
| DIMM-Bestückung | pro Sockel und Speicherkanal symmetrisch | stabiler Speicherbandbreite und lokale Kapazität | Kanalbelegung, Takt und Kapazität je Knoten |
| VM-Design | vNUMA an physische Knotengröße anpassen | reduziert unnötige Remote-Allokation | CPU-Ready-Zeit, Knotenlast, Gasttopologie |
NUMA-BIOS-Einstellungen optimieren keinen Server durch Aktivierung möglichst vieler Optionen. Sie stellen die Hardwaretopologie so dar, dass Betriebssystem, Hypervisor und Anwendung lokal arbeiten können. Node Interleaving aus. Speicherkanäle symmetrisch belegen. NPS und SNC nur so fein aufteilen, wie die reale Last es verwerten kann. Das ist die belastbare Reihenfolge.