# NUMA Mastery: Den Speicherpfad in Multi-Socket Systemen optimieren

TL;DR / Management Summary In modernen Servern mit zwei oder mehr CPUs ist der Arbeitsspeicher nicht mehr gleichmäßig angebunden. Jede CPU hat ihren eigenen “lokalen” RAM (NUMA Node). Greift CPU 1 auf den RAM von CPU 0 zu (Remote Access), steigt die Latenz massiv an. Ein Senior Admin nutzt numastat, um solche ineffizienten Zugriffe zu finden, und steuert mit numactl die Speicher-Allokations-Strategie (Local, Preferred oder Interleave), um das Maximum aus der Hardware herauszuholen.

# 1. Einführung & Architektur

Die Geographie des RAMs.

NUMA (Non-Uniform Memory Access) bedeutet: Der Zugriff auf den Speicher dauert unterschiedlich lange, je nachdem, welcher Kern auf welchen Riegel zugreift.

# Die Latenz-Falle (Mermaid)

graph LR
    subgraph "NUMA Node 0"
        A[CPU 0] --- B[Local RAM 0]
    end
    subgraph "NUMA Node 1"
        C[CPU 1] --- D[Local RAM 1]
    end
    A -->|Fast: 50ns| B
    C -->|Fast: 50ns| D
    A -->|Slow: 150ns| D
    C -->|Slow: 150ns| B
    B <-->|QPI / UPI / Infinity Fabric| D

# 2. Diagnose: Habe ich ein NUMA-Problem?

Zahlen lügen nicht.

# Den Aufbau verstehen

numactl -H
# Zeigt die Anzahl der Nodes, CPUs pro Node und die 'Distance' (Latenz-Faktor).

# Statistiken prüfen

numastat

Achten Sie auf numa_miss und numa_foreign. Wenn diese Werte hoch sind und stetig steigen, muss ein Prozess ständig auf den Speicher des anderen Sockels warten.

# 3. Strategien zur Speicher-Allokation

Die passende Politik wählen.

Mit numactl können wir das Verhalten des Kernels beim Reservieren von RAM steuern.

# 1. Membind (Strikte Trennung)

Der Prozess darf nur RAM vom eigenen Node nutzen. Wenn dieser voll ist, wird geswappt (statt Remote-RAM zu nutzen).

numactl --membind=0 ./my_app

# 2. Interleave (Gleichmäßige Verteilung)

Daten werden über alle Nodes verteilt. Ideal für Applikationen, die mehr RAM brauchen, als ein einzelner Sockel bietet (z.B. große Caches/In-Memory DBs).

numactl --interleave=all ./redis-server

# 4. Day-2 Operations: Automatischer Balancer

Der Kernel hilft mit.

Linux hat einen eingebauten Automatic NUMA Balancer. Er versucht, Speicherseiten automatisch zu der CPU zu verschieben, die am häufigsten darauf zugreift.

# Status prüfen und steuern

# 1 = Aktiviert, 0 = Deaktiviert
sysctl kernel.numa_balancing

# 5. Troubleshooting & “War Stories”

Wenn das System trotz freiem RAM swappt.

# Story 1: “Der plötzliche Swap-Tod”

Symptom: free -m zeigt 64GB freien RAM an, aber das System beginnt massiv zu swappen. Die Performance bricht ein. Ursache: NUMA Imbalance. Ein Prozess ist an Node 0 gebunden. Der RAM von Node 0 ist zu 100% voll, während Node 1 komplett leer ist. Der Kernel beginnt zu swappen, da der Prozess keinen Zugriff auf Node 1 hat. Lösung: Stellen Sie den Prozess auf --preferred statt --membind um oder nutzen Sie --interleave, um den RAM über alle Sockel zu streuen.

# Story 2: “Das langsame Backup”

Symptom: Ein Backup-Server mit 2 CPUs erreicht nur 300MB/s beim Komprimieren, obwohl 10Gbit Netzwerk und schnelle NVMe vorhanden sind. Ursache: Der Backup-Prozess liest Daten von einer NVMe, die an CPU 0 hängt, läuft aber selbst auf CPU 1. Jedes Byte muss über den langsamen Inter-Socket-Bus (UPI/QPI). Lösung: Pinnen Sie den Prozess an den Node, an dem die Hardware (NIC/Storage) hängt. Finden Sie den Node via: cat /sys/class/net/eth0/device/numa_node.

# 6. Fazit & Empfehlung

• Virtualisierung: Achten Sie bei Proxmox/KVM auf die Einstellung “NUMA: on” in den VM-Optionen, damit der Gast die Hardware-Topologie versteht.
• Wahl: Nutzen Sie --interleave für Applikationen, die den gesamten RAM des Servers brauchen.
• Hardware: Achten Sie beim Kauf auf eine symmetrische Bestückung der RAM-Bänke pro CPU.

# Anhang: Cheatsheet