NUMA-Bewusstsein und CPU-Pinning für dedizierte Server

Auf jedem Multi-Socket-Server sind die Fragen, wo ein Prozess läuft und wo sich sein Speicher befindet, zwei verschiedene Dinge, und wenn diese nicht synchronisiert sind, ist das einer der einfachsten Wege, Leistung zu verschenken. NUMA-Bewusstsein und CPU-Pinning sind die beiden Hebel, mit denen sich dies beheben lässt. Dieser Beitrag behandelt, wie NUMA funktioniert, wie man es unter Linux überprüft und wie man Workloads für Datenbanken, KI-Training und latenzempfindliche Dienste korrekt bindet.

So funktioniert NUMA auf Servern mit mehreren Sockeln

Ein NUMA-Knoten (Non-Uniform Memory Access) ist eine Gruppe von CPU-Kernen, die über einen dedizierten Speichercontroller an einen lokalen RAM-Block gebunden sind. Auf einem Server mit zwei Sockeln gibt es in der Regel zwei Knoten. Jeder Kern kann jede Adresse lesen, aber der lokale Zugriff dauert etwa 80 ns, während ein socketsübergreifender Hop über Intels UPI oder AMDs Infinity Fabric etwa 130–150 ns beträgt. Auf größeren Systemen mit mehr Sockets kann der Knoten im ungünstigsten Fall 250 ns überschreiten.

Die Bandbreite folgt dem gleichen Muster. Ein Sapphire-Rapids-System mit zwei Sockeln kann etwa 600 GB/s aufrechterhalten, wenn Kerne auf den lokalen Speicher zugreifen, aber die Verbindung zwischen den Sockeln beträgt nur einen Bruchteil davon, sodass der Datenverkehr, der diese überquert, schnell zu einem Engpass wird. Prozessoren mit vielen Kernen machen dies feiner: Intels Sub-NUMA Clustering (SNC) und AMDs Nodes Per Socket (NPS) teilen jeden Sockel in mehrere NUMA-Domänen auf, sodass ein „Zwei-Sockel“-System Linux problemlos vier oder acht Knoten präsentieren kann.

Ohne NUMA-Unterstützung migriert der Linux-Scheduler einen Thread problemlos zwischen Sockets, während dessen Arbeitsspeicher auf dem ursprünglichen Knoten verbleibt. Jeder nachfolgende Zugriff wird zu einem Remote-Zugriff. Das sichtbare Symptom ist eine hohe CPU-Auslastung bei geringem tatsächlichem Durchsatz, da die Kerne ihre Zeit damit verbringen, auf den Speicher zu warten. I/O-Geräte verschlimmern dies noch. Eine GPU oder ein NIC ist an einen bestimmten PCIe-Root angeschlossen, der zu einem NUMA-Knoten gehört. Wenn der Prozess, der Daten an dieses Gerät liefert, auf dem anderen Sockel läuft, durchläuft jeder DMA-Transfer die Verbindung.

Überprüfung der NUMA-Topologie unter Linux

Vier Tools decken fast alles ab, was Sie benötigen:

• lscpu für eine schnelle Übersicht über Sockets und Knoten.
• numactl --hardware für die Gesamtspeichergrößen der Knoten und die Matrix der Abstände zwischen den Knoten.
• numastat für Hit/Miss-Zähler pro Prozess.
• lstopo (aus hwloc) für die Cache-Hierarchie und die PCIe-Gerätelokalität.

Beginnen Sie mit numactl --hardware. Hier werden alle Knoten, die dazugehörigen Kerne und Speicher sowie die Abstandsmatrix aufgelistet. Ein Wert von 10 ist lokal, 20+ ist remote. Wenn Sie auf einem System mit mehreren Sockeln nur einen einzigen Knoten sehen, hat Ihr BIOS „Node Interleaving“ aktiviert und verbirgt die Topologie; beheben Sie dies zuerst (siehe unten).

Für einen bestimmten Prozess numastat -p <PID> wird aufgeschlüsselt, wo sein Speicher tatsächlich zugewiesen ist. Vier Zähler sind wichtig:

• numa_hit: auf dem vorgesehenen Knoten zugewiesener Speicher. Dieser Wert sollte hoch sein.
• numa_miss: Der vorgesehene Knoten war voll, die Zuweisung erfolgte an anderer Stelle.
• numa_foreign: Ein anderer Knoten hat versucht, lokal zuzuweisen, konnte dies aber nicht; dies deutet auf Speicherengpässe hin.
• other_node: Seiten, die auf einem anderen Knoten als demjenigen zugewiesen wurden, auf dem der Prozess läuft. Hohe Werte hier sind ein klassisches Anzeichen für schlechtes Pinning.

Für GPU- oder NIC-Workloads führen Sie lstopo-no-graphics und prüfen Sie, an welchen NUMA-Knoten jedes PCIe-Gerät angeschlossen ist. Befinden sich die Kerne, die das Gerät ansteuern, auf einem anderen Knoten, ist dies das Erste, was behoben werden muss.

CPU-Pinning und Speicherrichtlinien

CPU-Pinning (oder CPU-Affinität) bindet einen Prozess an bestimmte Kerne, sodass der Scheduler ihn nicht migrieren kann. Das allein reicht jedoch nicht aus, da Linux standardmäßig eine First-Touch-Speicherrichtlinie verwendet: Seiten werden dem Knoten zugewiesen, der als erster darauf schreibt. Wenn ein Thread auf dem falschen Knoten startet, bevor er gepinnt wird, bleibt sein Speicher dort. Sie müssen sowohl die Platzierung als auch die Zuweisung gemeinsam steuern.

Drei Tools decken die gängigen Fälle ab:

numactl unterstützt vier Speicherrichtlinien:

• --membind=N: Zuweisung nur auf Knoten N, Fehler bei Vollbelegung.
• --preferred=N: Knoten N bevorzugen, bei Bedarf auf andere ausweichen.
• --interleave=all: Round-Robin über alle Knoten für eine gleichmäßige Bandbreitenverteilung.
• --localalloc: Zuweisung auf den Knoten, auf dem sich die laufende CPU befindet.

Eine Arbeitslast an einen Knoten binden

Identifizieren Sie zunächst, welche Kerne zu Ihrem Zielknoten gehören:

numactl --hardware

Starten Sie dann die Anwendung, die sowohl für die Kerne als auch für den Speicher an diesen Knoten gebunden ist:

numactl --cpunodebind=0 --membind=0 ./your_application

Bei einem bereits laufenden Prozess passen Sie die CPU-Affinität mit taskset:

taskset -cp 0-7 <PID>

Damit die Einstellung auch nach einem Neustart erhalten bleibt, legen Sie sie in der systemd-Unit fest:

[Service]
CPUAffinity=0-7
NUMAPolicy=bind
NUMAMask=0

Laden Sie die Datei neu und starten Sie den Systemd-Dienst neu:

sudo systemctl daemon-reload && sudo systemctl restart <service>

Wenn Sie die Zuordnung manuell vornehmen, deaktivieren Sie den Auto-Balancer des Kernels, damit er Ihre Platzierung nicht beeinträchtigt:

sysctl -w kernel.numa_balancing=0

Fügen Sie dies /etc/sysctl.conf , um die Einstellung dauerhaft zu speichern. Überprüfen Sie anschließend mit numastat -p <PID> über einige Minuten mit realer Auslastung. Wenn other_node nahe Null bleibt, wirkt die Zuordnung.

Auswahl einer Strategie nach Workload

Die richtige Vorgehensweise hängt davon ab, ob Ihre Workload mehr von einer geringen Latenz oder von der Gesamtbandbreite über alle Knoten hinweg profitiert.

Speziell für GPU-Workloads: Führen Sie lstopo aus, um festzustellen, auf welchem NUMA-Knoten sich die GPU befindet, und starten Sie dann den Trainings- oder Inferenzprozess mit numactl --cpunodebind=N --membind=N für denselben N. Dies ist eine der einfachsten Optimierungsmaßnahmen auf einem Multi-Socket-GPU-Server, da die Standardplatzierung des Schedulers oft falsch ist.

Für HPC- und MPI-Workloads, die sich über beide Sockel erstrecken, binden Sie jeden Rank mit localalloc anstatt alles zu verschachteln. Jeder Rang erhält lokalen Speicher, und die Parallelität findet auf Rangebene statt.

Ein praktischer Hinweis: Wenn Sie einen Rank an einen einzelnen Knoten binden, lassen Sie dort 2–4 GB Spielraum. Ein Knoten, der fast voll ausgelastet ist, löst eine Speicherrückgewinnung aus, was Sie die Latenz kostet, die Sie eigentlich einsparen wollten.

Zu überprüfende BIOS- und Kernel-Einstellungen

Die Genauigkeit der Tool-Ausgabe hängt von der Topologie ab, die die Firmware offenlegt. Einige Einstellungen, die überprüft werden sollten:

• Node Interleaving: Deaktivieren Sie diese Option. Wenn sie aktiviert ist, stellt das BIOS den gesamten Speicher als einen einzigen flachen Pool dar und verbirgt NUMA vollständig vor dem Betriebssystem. numactl --hardware In diesem Fall wird auf einem System mit mehreren Sockeln nur ein Knoten angezeigt.
• Sub-NUMA-Clustering (Intel) oder Nodes Per Socket (AMD): Aktivieren Sie diese Option bei Prozessoren mit vielen Kernen, wenn Sie eine feinere Lokalisierung wünschen. Wird lscpu nach dem Neustart.
• vm.zone_reclaim_mode: Setzen Sie den Wert für die meisten Produktionsserver auf 0. Ein Wert ungleich Null gewinnt lokalen Speicher aggressiv zurück, anstatt ihn remote zuzuweisen, was nützlichen Seiten-Cache verdrängen kann.
• kernel.numa_balancing: Für allgemeine Workloads aktiviert lassen, deaktivieren, wenn Sie manuell festlegen. Der Auto-Balancer migriert Seiten und Threads auf eine Weise, die im Widerspruch zu Ihrer Richtlinie steht.

Wenn Sie NUMA-Tuning auf Bare-Metal-Systemen durchführen, bei denen Sie BIOS, Kernel-Parameter und IRQ-Affinität kontrollieren, können Sie alle oben genannten Einstellungen anwenden, ohne Hypervisor-Abstraktionen umgehen zu müssen. Das ist der Hauptgrund, warum diese Art von Arbeit auf dedizierter Hardware einfacher ist als in Cloud-VMs.

Für dedizierte Server mit mehreren Sockeln und vollständigem Root-Zugriff siehe die dedizierten Server von FDC.