Server CPU Affinity: Optimierung im Hosting-Betrieb

Server CPU Affinity ordnet Prozesse gezielt festen CPU-Kernen zu und reduziert so Migrationen, Kontextwechsel und kalte Caches in Hosting-Stacks. Ich zeige, wie dieses Pinning planbare Latenzen, höhere Cache-Trefferquoten und einen gleichmäßigen Durchsatz in Webservern, PHP-FPM, Datenbanken, VMs und Containern schafft.

Zentrale Punkte

Die folgenden Kernaspekte bilden die Leitplanken für eine effektive Umsetzung von Affinity im Hosting.

• Cache-Nähe minimiert Latenz und steigert die Effizienz bei multithreaded Workloads.
• Planbarkeit durch Pinning: weniger Ausreißer bei p99 und konstante Antwortzeiten.
• NUMA-Bewusstsein koppelt Speicher und CPU, reduziert teure Remote-Zugriffe.
• Cgroups ergänzen Affinity mit Quoten, Prioritäten und fairer Verteilung.
• Monitoring mit perf/Prometheus deckt Migrationen und Misses auf.

Was bedeutet CPU Affinity im Hosting?

Affinität bindet Threads an feste Kerne, damit der Scheduler sie nicht über das gesamte Socket streut. Dadurch bleiben L1/L2/L3-Caches warm, was vor allem bei latenzkritischen Webanfragen zählt. Der Linux CFS balanciert per Default dynamisch, erzeugt in heißen Phasen aber überflüssige Migrationen. Ich begrenze diese Wanderungen gezielt, statt den Scheduler komplett auszubremsen. Einen tieferen Einstieg in CFS-Alternativen gebe ich hier: Linux-Scheduler-Optionen.

Workload-Analyse und Profiling

Bevor ich pinne, untersuche ich die Charakteristik der Dienste. Ereignisgesteuerte Webserver erzeugen wenige Kontextwechsel, profitieren aber stark von Cache-Kohärenz. Datenbanken reagieren empfindlich auf Kernel-Migrationen während intensiver Joins oder Checkpoints. Ich messe p95/p99-Latenz, verfolge CPU-Migrations mit perf und schaue auf LLC-Misses. Erst dann schreibe ich feste Regeln und teste sie unter Peak-Last.

CPU-Topologie, SMT und Core-Paare

Ich berücksichtige die physische Topologie: Core-Komplexe, L3-Slices und SMT-Geschwister. Bei tail-latency-kritischen Diensten belege ich pro Core nur einen SMT-Thread, damit sich Hot-Threads keine Ausführungseinheiten teilen. SMT bleibt für Batch-Jobs aktiv, die vom zusätzlichen Durchsatz profitieren. Auf AMD‑EPYC achte ich auf CCD/CCX‑Grenzen: Worker bleiben innerhalb eines L3‑Segments, damit LLC‑Treffer stabil hoch bleiben. Bei NIC‑lastigen Stacks paare ich RX/TX‑Queues mit den Kernen, auf denen die Userspace-Worker laufen. Diese Paarung vermeidet Cross‑Core‑Snoops und hält die Pfade zwischen IRQ, SoftIRQ und App kurz.

Pinning-Strategien für Webserver und PHP-FPM

Für Webfrontends setze ich NGINX häufig auf ein enges Kern-Set, zum Beispiel 0–3, um gleichmäßige Antwortzeiten zu sichern. PHP-FPM splitte ich: Hot-Worker auf 4–7, Hintergrundjobs auf 8–11. Node.js entlaste ich mit Worker-Threads und binde CPU-lastige Tasks an eigene Kerne. Apache im event-MPM halte ich mit straffen Limits in kurzen Run-Queues. Solche Layouts halten Pipelines sauber und reduzieren Jitter spürbar.

Kernel- und Scheduler-Parameter im Kontext von Affinity

Affinity wirkt stärker, wenn der Kernel nicht permanent gegensteuert. Ich erhöhe bei stark cache-sensitiven Diensten die sched_migration_cost_ns, damit der CFS Migrationen seltener als „billig“ betrachtet. sched_min_granularity_ns und sched_wakeup_granularity_ns beeinflussen Zeitscheiben und Preemption-Verhalten; hier taste ich mich in A/B‑Tests vor. Für isolierte Latenzkerne setze ich gezielt housekeeping-CPUs und platziere RCU/Kernel-Threads abseits der Hot-Cores (nohz_full/rcu_nocbs auf ausgewählten Hosts). Diese Eingriffe sind kontextabhängig: Ich ändere sie nur pro Workload-Klasse und rolliere sie mit enger Beobachtung wieder zurück, wenn Varianz oder Durchsatz leiden.

Datenbanken und Affinity-Masken

In Datenbanken trennt eine gute Zuordnung Online-Transaktionen, Wartungsjobs und I/O-Handling. SQL-Server unterstützt Affinity-Masken, mit denen ich CPU-Sets für Engine-Threads und getrennt für I/O festlege. Ich vermeide Überlappungen zwischen Affinity-Mask und I/O-Mask, sonst konkurrieren Hot-Threads mit Block-I/O. Für Hosts mit über 32 Kernen nutze ich die erweiterten 64-Bit-Masken. So bleiben Log-Flusher, Checkpointer und Query-Worker sauber voneinander isoliert.

Storage-Pfade und NVMe-Queues

Bei blk‑mq mappe ich NVMe- und Storage‑Queues auf Kerne derselben NUMA‑Domäne wie die DB‑Worker. Log‑Flush‑Threads und die zugehörigen NVMe‑Queue‑IRQs landen auf benachbarten Cores, damit Write‑Bestätigungen nicht quer über den Socket laufen. Ich achte darauf, dass App‑Threads und stark beanspruchte Storage‑IRQs nicht denselben Kern teilen, sonst entstehen Head‑of‑Line‑Blöcke. Multiqueue‑Scheduler nutze ich so, dass die Zahl der Queues zu den tatsächlich zugewiesenen Cores passt – zu viele Queues erhöhen nur Overhead, zu wenige erzeugen Lock‑Contention.

Virtualisierung, vCPU-Pinning und NUMA

In KVM oder Hyper‑V kopple ich vCPUs an physische Kerne, um Steal-Time zu vermeiden. Ich trenne vhost‑net/virtio‑Queues von Hot-Kernen der Gäste, damit IO nicht die App-Threads drosselt. NUMA erfordert zusätzlich ein Auge auf Speicherlokalität, sonst verdoppeln sich die Zugriffszeiten. Für tieferen Hintergrund zu Topologien und Tuning verweise ich auf diesen Beitrag: NUMA-Architektur im Hosting. In dichten Setups bringt diese Kopplung spürbar gleichmäßigere Latenzen.

Container-Orchestrierung: cpuset-Policies und QoS

In Containern setze ich cpuset.cpus konsistent mit CPU‑Quoten. Kubernetes liefert mit dem CPU‑Manager (Policy „static“) exklusive Kerne für Pods in der QoS‑Klasse Guaranteed, wenn Requests=Limits gesetzt sind. So landen kritische Pods auf festen Cores, während Best‑Effort‑Workloads flexibel bleiben. Ich plane Pods topologiebewusst: Latenzpfade (Ingress, App, Cache) teile ich pro NUMA‑Node ein, damit Speicher und IRQ‑Last lokal bleiben. Wichtig ist die Planbarkeit auch bei Rollouts: Replikas erhalten identische Kern‑Sets, sonst driften Messwerte zwischen Instanzen auseinander.

Cgroups, Fairness und Isolierung

Affinity allein garantiert keine Fairness, deshalb kombiniere ich sie mit Cgroups. cpu.shares priorisiert Gruppen relativ, cpu.max setzt harte Obergrenzen pro Zeitscheibe. So halte ich laute Nachbarn im Zaum, selbst wenn sie CPU-bound laufen. In Multi-Tenant-Hosting sichere ich kritische Dienste mit höheren Shares ab. Zusammengenommen entsteht eine klare Trennung ohne Overcommit-Risiken.

Energie- und Frequenzmanagement für planbare Latenzen

Power-States beeinflussen Jitter spürbar. Für strikte p99‑Ziele halte ich auf Hot‑Cores hohe Grundfrequenzen stabil (Governor performance bzw. hohe energy_performance_preference) und begrenze tiefe C‑States, damit Aufwachzeiten nicht dominieren. Turbo nutze ich maßvoll: Einzelne Threads profitieren, aber thermische Limits können parallel laufende Kerne drosseln. Für gleichmäßigen Durchsatz setze ich obere/untere Frequenzgrenzen pro Socket und verlege Energiesparlogik auf Cold‑Cores. Das reduziert die Varianz, ohne den Gesamtdurchsatz übermäßig zu beschneiden.

systemd, taskset und Windows: Umsetzung

Für dauerhafte Dienste nutze ich systemd mit CPUAffinity=0-3 in der Unit, kombiniert mit CPUSchedulingPolicy=fifo bei RT‑Workloads. Einmalige Jobs starte ich mit taskset -c 4-7, damit Backups nicht in Hot-Caches funken. Container kapsle ich via cpuset.cpus und cgroupv2, sodass Pods ihre festen Kerne erhalten. Unter Windows setze ich die ProcessorAffinity per PowerShell auf ein Bitmasken‑Hex. Diese Optionen geben mir präzise Kontrolle bis zur Kernel-Grenze.

Monitoring und Tests: messen statt raten

Ich prüfe den Erfolg mit perf (context-switches, migrations, cache-misses) und verfolge p95/p99 per Timeseries. Workload-Replays mit wrk, hey oder sysbench zeigen, ob Ausreißer kleiner werden. Zusätzlich beobachte ich Steal-Time in VMs und IRQ-Last auf Host-Kernen. Ein kurzer A/B‑Vergleich unter Peaklast macht falsche Annahmen sichtbar. Erst wenn Zahlen passen, friere ich Regeln als dauerhafte Policies ein.

Risiken, Grenzen und Anti-Patterns

Starres Pinning kann Kerne leerlaufen lassen, wenn Traffic schwankt. Ich setze deshalb nur kritische Threads fest und lasse unkritische auf dem Scheduler. Auch Overcommit frisst Nutzen, wenn zwei laute VMs denselben Kern wollen. Wer zu viel fixiert, kämpft später mit Hotspots und schlechter Ausnutzung. Ein guter Reality‑Check: dieser Beitrag zu CPU‑Pinning ist selten sinnvoll mahnt zu maßvollem Einsatz mit klaren Zielen und schlüssigen Metriken.

Spezialfälle: High‑Frequency und Realtime

Für Sub‑Millisekunden verknüpfe ich Affinity mit RT‑Policy, IRQ‑Tuning und NUMA‑Konsistenz. Netz‑IRQs binde ich auf eigene Kerne und halte Userspace‑Threads fern davon. Auf AMD‑EPYC mit Chiplet‑Topologie sichere ich kurze Pfade zwischen Core, Memory‑Controller und NIC. Große Pages (HugeTLB) helfen, TLB‑Miss‑Raten zu drücken. Diese Schritte senken Varianz deutlich und schaffen Planbarkeit bei HF‑Traffic.

Feintuning für beliebte Stacks

Bei PHP-FPM setze ich pm dynamic mit passendem pm.max_children und process_idle_timeout, damit Leerlauf-Worker wegfallen. NGINX läuft mit worker_processes auto, jedoch binde ich Worker gezielt an die Hot-Kerne. Apache im event‑MPM halte ich kurz angebunden, damit die Run‑Queue nicht wächst. Für Node.js kapsle ich CPU‑Last in Worker‑Threads mit eigener Affinity. So bleibt die Event‑Loop frei und reagiert zügig auf I/O.

IRQ‑Steuerung und I/O‑Trennung

Ich pinne IRQ-Handler via smp_affinity auf dedizierte Kerne, damit Paketfluten keine App‑Threads verdrängen. Multiqueue‑NICs teile ich über mehrere Cores, passend zur RSS‑Verteilung. Storage‑Interrupts trenne ich von Netz‑IRQs, um Head‑of‑Line‑Blocking zu vermeiden. Async‑I/O und Threadpools in NGINX verhindern blockierende Syscalls auf Hot‑Kernen. Diese Trennung hält Pfade kurz und schützt Spitzenlast.

Leitfaden für die schrittweise Einführung

Ich starte mit Profiling unter Real‑Traffic und setze dann nur kritische Dienste fest. Danach prüfe ich p95/p99 und Migrationen, bevor ich weitere Threads binde. Cgroups geben mir Korrekturmöglichkeiten ohne Neustart. Änderungen dokumentiere ich pro Host und fasse Regeln in systemd‑Units. Erst nach stabilen Messwerten rolle ich die Konfiguration breit aus.

Betrieb, Change-Management und Rollback

Affinity-Regeln behandle ich wie Code. Ich versioniere systemd‑Units und cgroup‑Policies, rolle sie staged aus (zuerst Canaries, dann breiter) und halte einen klaren Rückweg bereit. Ein schneller Rollback ist Pflicht, wenn p99‑SLOs reißen oder Throughput sinkt. Ich friere Änderungen vor Peak‑Zeiten ein und beobachte nach jedem Schritt Migrations‑Raten, LLC‑Miss‑Quoten und Utilization pro Kern. Das reduziert Betriebsrisiken und verhindert, dass „gute“ Einzeloptimierungen im Verbund unerwünschte Seiteneffekte erzeugen.

Security- und Isolationseffekte

Affinity hilft auch bei Isolation: In Multi‑Tenant‑Umgebungen teile ich keine SMT‑Geschwister zwischen Mandanten, um Crosstalk und Seitenkanäle zu minimieren. Sensible Dienste laufen auf exklusiven Cores, getrennt von lauten IRQ‑Quellen. Kernel‑Mitigations gegen Speculative‑Execution‑Lücken erhöhen Kontextwechsel‑Kosten – sauberes Pinning dämpft den Effekt, weil weniger Threads über Kachelgrenzen wandern. Wichtig: Security‑Ziele und Performance‑Ziele ausbalancieren; manchmal ist „SMT off“ für wenige, besonders schützenswerte Workloads gerechtfertigt, während der Rest weiterhin von SMT‑Durchsatz profitiert.

KPIs, SLOs und Wirtschaftlichkeit

Ich definiere vorab klare KPIs: p95/p99‑Latenz, Durchsatz, cs/req (Context‑Switches pro Anfrage), Migrations pro Sekunde und LLC‑Miss‑Rate. Zielkorridore helfen, Trade‑offs zu bewerten, etwa „p99 −25% bei ≤5% weniger Max‑Durchsatz“. Auf Host‑Ebene beobachte ich Core‑Imbalance und Idle‑Zeit, damit Pinning nicht zu teurem Leerstand führt. Wirtschaftlich sinnvoll ist Affinity, wenn die erzielte Planbarkeit SLO‑Strafen reduziert oder die Dichte in Clustern steigert, weil Reservepuffer kleiner ausfallen dürfen. Ohne diese Zahlenschiene bleibt Pinning Bauchgefühl – mit ihr wird es zu einer belastbaren Optimierung.

Rückblick und Einordnung

Affinity liefert auf Servern mit vielen Cores oft erstaunlich viel Planbarkeit für geringe Eingriffe. In VMs mit Overcommit oder stark schwankendem Traffic drossele ich den Einsatz. NUMA‑Bewusstsein, IRQ‑Tuning und faire Quoten entscheiden über den Erfolg. Ohne Monitoring wird Pinning schnell zur Last, mit Zahlen bleibt es ein Werkzeug. Wer selektiv vorgeht, gewinnt Vorhersagbarkeit und nutzt Hardware effizient aus.

Zusammenfassung

Ich nutze Server‑CPU‑Affinity, um Hot‑Threads nahe an ihren Daten zu halten, Migrationen zu reduzieren und Latenzspitzen zu glätten. In Webservern, PHP‑FPM, Datenbanken und VMs kombiniere ich Affinity mit Cgroups, IRQ‑Tuning und NUMA‑Disziplin. Systemd‑Optionen, taskset und Container‑cpusets machen die Umsetzung alltagstauglich. Mit Messungen per perf und Zeitenreihen sichere ich den Effekt ab und drehe schrittweise an den Reglern. Wer Pinning gezielt einsetzt, erhält konstante Antwortzeiten, saubere Caches und einen messbar höheren Durchsatz.