# CPU Pinning Masterclass: Cache-Lokalität perfekt nutzen

TL;DR / Management Summary In modernen Multi-Core Systemen ist der Weg der Daten entscheidend. Wenn ein Prozess ständig zwischen CPU-Kernen springt, gehen wertvolle Informationen im L1/L2 Cache verloren. Ein Senior Admin nutzt CPU Pinning (Affinität), um kritische Prozesse (z.B. Datenbank-Engines oder VCPUs von VMs) fest an spezifische Kerne zu binden. In Kombination mit der Isolation von Kernen mittels isolcpus schaffen wir eine Umgebung, in der die Applikation die exklusive Herrschaft über die Hardware hat.

# 1. Einführung & Architektur

Das Problem des ‘Context Hopping’.

Der Kernel-Scheduler (Artikel 379) versucht, alle Kerne gleichmäßig auszulasten.

• Folge: Ein Prozess wird auf Kern 0 gestartet, dort wird der Cache mit seinen Daten gefüllt. Dann wird er pausiert und auf Kern 4 fortgesetzt. Der Cache auf Kern 4 ist leer -> Cache Miss. Die Performance bricht ein.

# Die Hardware-Sicht (Mermaid)

graph TD
    subgraph "CPU Socket 0 (NUMA Node 0)"
        A[Core 0: Cache L1/L2] --- B[L3 Cache]
        C[Core 1: Cache L1/L2] --- B
        B --- D[Local RAM]
    end
    subgraph "CPU Socket 1 (NUMA Node 1)"
        E[Core 8: Cache L1/L2] --- F[L3 Cache]
        G[Core 9: Cache L1/L2] --- F
        F --- H[Local RAM]
    end
    B <-->|Slow Interconnect| F
    I[Process: pinning to Core 0] --> A

# 2. Praktisches Pinning mit taskset

Sofortige Bindung.

# Einen neuen Prozess gebunden starten

# -c: Liste der Kerne (0 und 1)
taskset -c 0,1 /usr/local/bin/my_database

# Einen laufenden Prozess pinnen

sudo taskset -cp 4-7 <PID>

# 3. Core Isolation: isolcpus

Der Privat-Kern für die Applikation.

Mit dem Boot-Parameter isolcpus sagen wir dem Kernel: “Fasse diese Kerne niemals für normale Aufgaben an”. Nur wenn wir explizit via taskset einen Prozess dorthin schicken, werden sie genutzt.

# Einrichtung (GRUB)

Hängen Sie folgendes an die Kernel-Zeile an: isolcpus=2,3 Nach dem Reboot werden auf Kern 2 und 3 keine System-Dienste oder User-Shells mehr laufen.

# 4. Day-2 Operations: NUMA Awareness

Den RAM-Pfad beachten.

Auf Systemen mit mehreren CPU-Sockeln hat jeder Sockel seinen eigenen, direkt angebundenen RAM. Zugriff auf den RAM des anderen Sockels ist langsam.

# numactl nutzen

Stellen Sie sicher, dass der Prozess auf dem gleichen Sockel läuft, an dem auch sein RAM hängt.

# Starte App auf NUMA Node 0 mit lokalem Speicher-Zugriff
sudo numactl --cpunodebind=0 --membind=0 ./my_high_perf_app

# 5. Troubleshooting & “War Stories”

Wenn Pinning zum Flaschenhals wird.

# Story 1: “Der hängende Interrupt”

Symptom: Ein Prozess ist fest an Kern 0 gepinnt. Die Performance ist trotzdem schlecht. top zeigt, dass Kern 0 zu 50% mit softirq beschäftigt ist. Ursache: Die Netzwerkkarte schickt alle Interrupts (Anfragen) standardmäßig an Kern 0. Der gepinnte Prozess muss ständig für die Netzwerkkarte unterbrechen. Lösung: Nutzen Sie IRQ-Affinität. Schieben Sie die Interrupts der Netzwerkkarte auf andere Kerne: echo 2 > /proc/irq/<irq_id>/smp_affinity (Bitmask für Kern 1).

# Story 2: “Das VM-Overcommitment”

Symptom: In einer Proxmox-Umgebung wurden alle VCPUs der VMs fest an physische Kerne gepinnt. Die Performance ist schlechter als vorher. Ursache: Zu viele VCPUs teilen sich den gleichen gepinnten Kern. Da der Kernel den Prozess nicht mehr auf einen freien Kern schieben darf, muss die VM warten, bis der Kern frei wird. Lösung: Pinnen Sie nur dann, wenn Sie weniger VCPUs als physische Kerne haben, oder nutzen Sie CPU-Shares/Weights (Artikel 375) für die dynamische Steuerung.

# 6. Fazit & Empfehlung

• Pflicht: Nutzen Sie numactl, um bei Datenbanken (Oracle, SAP) sicherzustellen, dass RAM und CPU auf dem gleichen Node liegen.
• Wahl: Nutzen Sie isolcpus nur für extrem zeitkritische Aufgaben (Real-Time, Trading, Messwerterfassung).
• Monitoring: Nutzen Sie btop (Artikel 265), um die Auslastung der einzelnen Kerne visuell zu prüfen.

# Anhang: Cheatsheet