Energieoptimierung im Rechenzentrum: CPU-Freq-Governors, C-States und ihre Latenz-Auswirkungen

Die Energieoptimierung im Rechenzentrum ist längst kein reines Kostenthema mehr. Sie beeinflusst thermische Stabilität, Hardware-Lebensdauer, Dichte pro Rack und nicht zuletzt die Planbarkeit von Performance. In der Praxis entscheidet oft eine unscheinbare Kombination aus CPU-Frequenzregelung (CPU-Freq-Governors) und CPU-Schlafzuständen (C-States, also Idle-States) darüber, ob Systeme „satt“ und vorhersehbar laufen oder ob plötzlich Latenzspitzen auftreten, die sich nur schwer reproduzieren lassen.

Dieser Beitrag ordnet die Mechanismen sauber ein und übersetzt sie in Betriebsentscheidungen: Was lässt sich gefahrlos sparen? Wo steigt das Risiko für Jitter (Schwankungen in Antwortzeiten)? Und wie gehen Sie insbesondere in Kubernetes-Umgebungen vor, in denen viele Workloads sich Hosts teilen, aber einzelne Anwendungen trotzdem harte Latenzanforderungen haben?

Energieoptimierung im Rechenzentrum in der Praxis

Auf modernen Server-CPUs gibt es zwei zentrale Stellhebel:

• Frequenz-/Spannungs-Skalierung über P-States (Performance-States): Die CPU taktet höher oder niedriger, oft gekoppelt an die Versorgungsspannung. Ein CPU-Freq-Governor ist die Policy, die entscheidet, wie aggressiv hoch- oder runtergetaktet wird.
• Idle-Schlafzustände über C-States: Wenn ein Core nichts zu tun hat, kann er in immer tiefere Schlafzustände wechseln. Je tiefer der C-State, desto mehr Energie spart er, aber desto länger dauert typischerweise das Aufwachen (Exit Latency).

Das Missverständnis im Betrieb: „Mehr Sparen = immer langsamer“. Tatsächlich ist es differenzierter. Viele Workloads sind durchschnittlich nicht CPU-limitiert, profitieren aber von hoher Effizienz, solange Tail-Latenzen (z. B. 99. Perzentil) nicht aus dem Ruder laufen. Kritisch wird es vor allem dann, wenn Last bursty ist (kurze, häufige Peaks), oder wenn einzelne Threads/Requests sehr schnell bedient werden müssen und der Weg aus einem tiefen C-State oder von niedriger Frequenz zum „vollen Takt“ genau in diese Zeit fällt.

Weitere Verstärker sind typisch im Rechenzentrum: NUMA (Non-Uniform Memory Access, also unterschiedliche Speicherzugriffszeiten je nach CPU-Sockel), Shared Interrupts, Hyper-Threading/SMT (zwei Threads teilen Ressourcen eines Cores) und Virtualisierung/Containerisierung mit wechselnder CPU-Zuteilung.

CPU-Freq-Governors, P-States und Treiber: Was Admins wirklich wissen müssen

Unter Linux ist das CPU-Frequenz-Subsystem historisch gewachsen. Entscheidend ist, welcher Treiber aktiv ist, denn der Treiber definiert die realen Stellmöglichkeiten und die Beobachtbarkeit. Häufige Varianten:

• intel_pstate: Intel-spezifischer Treiber, oft Standard. Er nutzt Hardware/CPU-internes DVFS (Dynamic Voltage and Frequency Scaling) und bietet Policies wie „performance“/„powersave“. Die Namen können irreführen: „powersave“ bedeutet hier oft „hardware-managed, effizient“ und ist nicht zwingend „langsam“.
• amd_pstate: AMD-Äquivalent auf neueren Plattformen, je nach Kernel/BIOS-Reifegrad unterschiedlich gut.
• acpi-cpufreq: generischer ACPI-basierter Treiber, bietet klassische Governors wie „ondemand“, „conservative“ etc.

Die Governor-Policy entscheidet, wie schnell auf Last reagiert wird. In vielen Rechenzentrums-Setups sind Reaktionszeiten (Ramp-Up) wichtiger als Maximalfrequenz. Das heißt: Eine policy, die zügig hochskaliert, kann Tail-Latenzen stabilisieren, ohne dauerhaft im Maximaltakt zu laufen.

Schnelle Bestandsaufnahme auf Linux-Hosts

Für eine verlässliche Baseline sollten Sie zunächst Treiber, Governor und Frequenzgrenzen erfassen. Nutzen Sie dazu cpupower (Paketname je nach Distribution):

# Überblick: Treiber, Governor, aktuelle Frequenz, Grenzen
cpupower frequency-info

# Kurzstatus pro CPU (je nach Distribution verfügbar)
cpupower frequency-info -p

Zusätzlich lohnt ein Blick in sysfs (für Automatisierung/CMDB):

# Treiber und Governor pro CPU (CPU0 als Beispiel)
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# Grenzen (kHz)
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

Typische Stolperfalle: BIOS-Settings können Linux übersteuern oder einschränken (z. B. „Energy Efficient Turbo“, „C-State Control“, „Package C-State Limit“, „Power Regulator“). Wenn Sie auf OS-Ebene drehen, aber BIOS/Management-Controller setzt harte Limits, sehen Sie scheinbar „korrekte“ Policies, aber keine Wirkung.

C-States verstehen: Core vs. Package und die Exit-Latenz

C-States sind Idle-Zustände. Ein Core kann in C1 (sehr flach) bis hin zu tieferen Zuständen wechseln. Zusätzlich gibt es Package C-States, bei denen der ganze CPU-Sockel (das „Package“) tiefer schläft, wenn genug Kerne idle sind. Genau diese Package-Zustände sind oft die Quelle schwer erklärbarer Latenzspitzen, weil das Aufwachen mehr Komponenten betrifft (Uncore, Cache-Hierarchie, Interconnect).

Die relevante Betriebsfrage lautet nicht „Welche C-States sind an?“, sondern: Wie oft und wie lange residiert die CPU in welchen C-States, und korrelieren Exit-Latenzen mit Ihren SLOs (Service Level Objectives)?

C-State-Residency messen

Unter Linux liefert turbostat (aus den linux-tools) sehr brauchbare Hinweise. Es zeigt u. a. die prozentuale Residency in C-States sowie Frequenz-/Turbo-Verhalten. Beispiel:

# 10 Messzyklen à 1 Sekunde, kompakt
turbostat --quiet --Summary --interval 1 --num_iterations 10

Wenn Sie in Phasen, in denen Latenzspitzen auftreten, hohe Residency in tiefen Package-States sehen, ist das ein starkes Indiz. Umgekehrt: Wenn die CPU ohnehin selten tiefer als C1/C2 geht (z. B. wegen Hintergrundlast, Interrupts, Monitoring-Agenten), bringt aggressives C-State-Tuning oft wenig – und die Ursache liegt woanders (Scheduler, IRQ-Stürme, Storage, Netzwerk).

Typische Latenz-Symptome, die zu Governors/C-States passen

Nicht jede Latenz ist „Power“. Folgende Muster passen jedoch häufig zu Frequenz- und Idle-Themen:

• Spikes im Millisekundenbereich bei ansonsten stabiler Average-Latenz, oft bei bursty Requests (API-Gateways, Ingress, Auth, Cache-Miss-Pfade).
• Regelmäßige Jitter-Cluster im Sekundentakt, die mit Idle-/Wakeup-Zyklen korrelieren.
• Nur bestimmte Nodes sind betroffen (anderes BIOS-Profil, andere Microcode-/Kernel-Version, andere Power-Limits).
• Problem verschwindet unter Dauerlast (weil CPU nicht mehr tief idle ist) und tritt in „ruhigen“ Phasen auf.

Wichtig: Diese Symptome können auch von IRQ-Balancing, NUMA-Fernzugriffen, cgroup-CPU-Quota, CPU-Steal (bei Virtualisierung) oder Garbage-Collector-Pausen kommen. Deshalb ist eine Mess- und Ausschlussstrategie zentral.

Praxis-Workflow: Von der Hypothese zur belastbaren Entscheidung

Ein tragfähiger Prozess im Rechenzentrum braucht Reproduzierbarkeit, Telemetrie und Rollback. Ein bewährter Ablauf:

1. Workload klassifizieren: latency-sensitiv (z. B. Echtzeit-nahe Dienste), throughput-orientiert (Batch), gemischt (APIs mit Peaks).
2. SLOs und Messpunkte definieren: p95/p99 Latenz, Queue-Längen, Error-Budget, zusätzlich Energie/Temperatur (falls verfügbar).
3. Baseline messen: turbostat, cpupower, Systemlast, IRQ-Raten, Scheduler-Runqueue, Kubernetes-Metriken.
4. Änderung minimalinvasiv und nur auf ausgewählten Nodes (Canary): z. B. Governor ändern oder C-States begrenzen.
5. Vergleich gegen Baseline: gleiche Lastprofile, gleiche Zeitfenster, gleiche Messmethodik.
6. Rollback vorbereiten: OS/Boot-Parameter zurück, BIOS-Profil dokumentiert, Automations-Playbooks angepasst.

Umsetzung auf Linux: Governor setzen, Grenzen definieren, Persistenz herstellen

Für viele Server-Workloads ist ein pragmatischer Startpunkt: Governor „performance“ auf Latenz-kritischen Nodes, und ein effizienter Hardware-Policy-Mode (je nach Treiber) auf allgemeinen Nodes. Entscheidend ist die Node-Differenzierung, nicht ein globales Dogma.

Governor temporär setzen (Test)

# Performance-Policy für alle CPUs (temporär bis Reboot/Policy-Reset)
cpupower frequency-set -g performance

# Alternativ: powersave (bei intel_pstate oft "hardware-managed")
cpupower frequency-set -g powersave

Wenn cpupower scheitert, liegt es oft an fehlenden Rechten (sudo), fehlenden Modulen/Tools oder daran, dass der Treiber keine klassischen Governors anbietet (z. B. je nach intel_pstate-Modus). Prüfen Sie dann, was cpupower frequency-info als „available governors“ meldet.

Persistente Konfiguration mit tuned (RHEL-/CentOS-/Rocky-/Alma-Familie)

tuned ist ein Daemon, der Profile für Power/Performance anwendet. Für den Betrieb ist das oft stabiler als individuelle Skripte, weil es Boot-/Service-Reihenfolgen berücksichtigt.

# Status und aktives Profil
tuned-adm active

# Beispiel: auf Performance schalten (Host-weit)
tuned-adm profile performance

Stolperfalle: tuned kann auch IRQ-Balancing, Disk-Settings oder Netzwerkparameter verändern. Für gezieltes CPU-Tuning empfiehlt sich ein custom Profil, das nur die benötigten Stellschrauben setzt, statt ein großes Standardprofil blind zu übernehmen.

C-States begrenzen: sinnvoll, riskant, manchmal nötig

C-States zu begrenzen ist ein grober, aber wirksamer Hebel, wenn Exit-Latenzen die Tail-Latenz dominieren. Technisch passiert das häufig über Kernel-Boot-Parameter oder BIOS-Limits. Das reduziert Einsparpotenzial, kann aber Latenz stabilisieren.

Kernel-Boot-Parameter (beispielhaft) und Rollback-Fähigkeit

Welche Parameter sinnvoll sind, hängt von Plattform und Kernel ab. Häufig genutzte Stellschrauben sind:

• intel_idle.max_cstate: begrenzt die maximalen C-States im intel_idle Treiber.
• processor.max_cstate: generischer Limit-Parameter (wirkt je nach Treiber unterschiedlich).
• idle=poll: verhindert tiefe Idle-Zustände (sehr energiehungrig, eher als Diagnosemittel).

Setzen Sie solche Parameter zunächst auf einem Canary-Node und dokumentieren Sie den exakten Vorher/Nachher-Stand. Beispiel für GRUB (Distributionen unterscheiden sich; prüfen Sie Ihre Standards):

# 1) Aktuelle Kernel-Cmdline prüfen
cat /proc/cmdline

# 2) GRUB Default anpassen (Beispiel)
sudo sed -i 's/GRUB_CMDLINE_LINUX="/GRUB_CMDLINE_LINUX="intel_idle.max_cstate=1 processor.max_cstate=1 /' /etc/default/grub

# 3) GRUB-Konfig regenerieren (Pfad je nach Distribution)
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# 4) Reboot planen und nach dem Boot wieder prüfen
sudo reboot

Rollback ist identisch: Parameter entfernen, GRUB neu generieren, rebooten. Planen Sie dafür Wartungsfenster, denn es ist eine Boot-Änderung.

Wichtig für die Entscheidung: Wenn Sie C-States begrenzen, beobachten Sie auch Temperatur, Lüfterkurven und Power-Limits. In dichten Umgebungen kann das sekundäre Effekte haben (Thermal Throttling), die am Ende wieder Performance kosten – nur anders.

Kubernetes-spezifisch: Node-Tuning ohne Nebenwirkungen

In Kubernetes wird es anspruchsvoller, weil Workloads dynamisch verteilt werden. Energieoptimierung und Latenzstabilität sind hier keine „Host-Feintuning“-Übung, sondern eine Frage von Node-Rollen, Scheduling und Isolation.

Grundprinzip: Unterschiedliche Node-Pools für unterschiedliche SLOs

Wenn Sie latency-sensible Workloads (z. B. Ingress, Service-Mesh-Data-Plane, Auth, Message-Broker Frontends) und Batch/CI/ETL auf denselben Nodes mischen, wird jede Power-Policy zur Kompromissfalle. Besser:

• Node-Pool „low-latency“: konservative Energiesparmechanismen (höhere Performance-Policy, begrenzte C-States), strengere CPU-Isolation.
• Node-Pool „balanced“: effiziente Policies, aber mit Monitoring auf Tail-Latenz.
• Node-Pool „batch“: maximale Energieeffizienz, dafür höhere Toleranz für Jitter.

Diese Trennung setzen Sie über Labels/Taints/Tolerations um (Label = Kriterium, Taint = „nur mit Erlaubnis“). Das verhindert, dass ein einzelnes Deployment Ihre globalen CPU-Policies diktiert.

CPU-Manager, Cgroups und „Guaranteed“-Pods

Der Kubelet CPU Manager kann Cores exklusiv an Pods vergeben (Policy „static“). Das reduziert Scheduler-Jitter, weil ein Pod nicht ständig zwischen CPUs wandert. Voraussetzung sind typischerweise Guaranteed Pods (Requests = Limits) für CPU. Cgroups (Control Groups, Ressourcenkontrolle im Kernel) setzen dabei die Limits durch; mit cgroup v2 sind manche Details anders, aber das Prinzip bleibt.

Für einen ersten Check: Welche cgroup-Version nutzen Ihre Nodes?

stat -fc %T /sys/fs/cgroup

Und ob der CPU Manager überhaupt aktiv ist (Kubelet-Konfiguration ist clusterabhängig). Auf vielen Systemen finden Sie die Konfiguration z. B. unter /var/lib/kubelet/config.yaml:

sudo grep -E "cpuManagerPolicy|cpuManagerReconcilePeriod" -n /var/lib/kubelet/config.yaml || true

Typische Stolperfalle: CPU-Manager „static“ bringt wenig, wenn gleichzeitig CPU-Frequenz aggressiv spart oder tiefe Package C-States aktiv bleiben. Exklusive Cores reduzieren Migration, aber nicht die Wakeup-Latenz aus tiefem Idle. Für Low-Latency-Nodes sollten diese Themen zusammen gedacht werden.

IRQ-Affinität und „Noisy Neighbors“

Interrupts (IRQs) sind Hardware-Ereignisse, die CPU-Zeit außerhalb normaler Prozesse verbrauchen. Wenn auf einem „exklusiven“ Core trotzdem viele NIC-/Storage-IRQs landen, ist die Isolation praktisch wertlos. Prüfen Sie daher IRQ-Last und Verteilung:

# IRQ-Statistik (Momentaufnahme)
cat /proc/interrupts | head -n 30

# Softirqs (Netzwerk/Block-Processing im Kernel)
cat /proc/softirqs | head -n 30

In Kubernetes ist ein häufiger Auslöser: Node-Local-DNS, CNI (Container Network Interface) und Storage-Plugins erzeugen Hintergrundverkehr, der auf „falschen“ CPUs abgearbeitet wird. Hier helfen je nach Plattform irqbalance-Konfiguration, CPU-sets und eine klare Trennung von „System-Cores“ und „Workload-Cores“ (z. B. über isolcpus/nohz_full als fortgeschrittene Optionen). Diese Schritte sind jedoch tiefgreifend und sollten nur mit sauberem Test- und Rollbackplan erfolgen.

Checkliste: Vor dem Tuning prüfen (damit Sie nicht das Falsche optimieren)

• BIOS/UEFI: Power-Profile, C-State-Limits, Turbo, SMT, deterministische Performance-Optionen. Dokumentieren Sie den Stand je Node-Modell.
• Mikrocode und Kernel: Unterschiedliche Stände verändern Power- und Idle-Verhalten messbar. Vereinheitlichen Sie, bevor Sie vergleichen.
• Virtualisierung: Bei VMs ist CPU-Steal/Host-Policy oft dominanter als Guest-Tuning. In diesem Beitrag geht es primär um Bare Metal oder Host-OS.
• Monitoring: Messen Sie p95/p99 und nicht nur Durchschnitt; korrelieren Sie mit CPU-Idle-Residency, Frequenz und IRQ-Raten.
• Lastprofil: Tuning unter synthetischer Dauerlast kann das reale Burst-Verhalten verfehlen.

Troubleshooting: Wenn nach dem Tuning neue Probleme auftauchen

Symptom: Höhere Temperaturen, aber keine bessere Latenz

Dann ist häufig nicht C-State-Exit die Ursache, sondern Queueing an anderer Stelle (Netzwerk, Storage, Lock-Contention) oder Thermal Throttling. Prüfen Sie, ob die CPU unter Last taktet wie erwartet und ob Power-Limits greifen. Bei vielen Servern liefern BMC/Redfish oder Hersteller-Tools die nötigen Werte; auf OS-Ebene hilft turbostat als Indikator.

Symptom: Mehr Durchsatz, aber schlechtere Tail-Latenz

Das deutet oft auf „zu aggressive“ Boost-/Turbo-Phasen hin, die in thermische Limits laufen, oder auf mehr Konkurrenz durch Background-Tasks (z. B. weil alles schneller wird, aber auch mehr parallel passiert). In Kubernetes: Prüfen Sie Pod-Dichte pro Node, CPU-Throttling (cgroup) und ob QoS-Klassen sauber gesetzt sind.

Symptom: Nur einzelne Pods sind betroffen

Dann sind CPU-Policies meist nur ein Faktor. Häufige Ursachen sind CPU-Quota/Throttling (Limits), ungünstige CPU-Affinitäten, GC-Pausen (bei JVM/.NET), oder „Noisy Neighbor“-Effekte durch Shared Caches/SMT. Für Latenz-kritische Pods sollten Sie Requests/Limits konsistent setzen und, wenn nötig, auf dedizierte Nodes ausweichen.

Rückfallstrategie: Wie Sie sicher wieder auf den Ausgangszustand kommen

Eine Rückfallstrategie ist keine Formalität, sondern der Unterschied zwischen kontrolliertem Experiment und nächtlicher Eskalation. Planen Sie mindestens diese Ebenen:

• OS-Policy Rollback: Governor zurücksetzen (cpupower/tuned), Services neu laden, dokumentierter Sollzustand in Konfigurationsmanagement.
• Boot-Parameter Rollback: GRUB-Änderungen revertieren, alte Kernel-Cmdline verfügbar halten, im Zweifel per Boot-Menü starten.
• Node-Pool Rollback in Kubernetes: Canary-Nodes aus dem Pool nehmen (cordon/drain), Workloads zurück auf „balanced“ verschieben, dann erst weiter ändern.

Für Kubernetes-Operationen (Canary/Drain) als Standardwerkzeugkasten:

# Node für neue Pods sperren
kubectl cordon <node-name>

# Pods kontrolliert evakuieren (Achtung: PDBs und Stateful Workloads)
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

# Nach Rollback wieder freigeben
kubectl uncordon <node-name>

Stolperfalle: Drain kann an PodDisruptionBudgets (PDB) oder lokalen Daten (emptyDir) scheitern. Das ist kein „Kubernetes-Problem“, sondern Teil der Betriebsrealität – und genau deshalb sollten Sie Power-/Latency-Tuning als kontrollierten Node-Pool-Prozess behandeln.

Best Practices: Energieeffizienz und Latenz stabil zusammenbringen

• Segmentieren statt global schrauben: Unterschiedliche Policies pro Node-Pool sind fast immer besser als ein Cluster-weiter Kompromiss.
• Messen Sie Residency, nicht nur Watt: C-State- und Frequenz-Metriken erklären Latenzspitzen oft besser als reine Leistungsaufnahme.
• Erst Treiber/BIOS vereinheitlichen: Ohne reproduzierbare Basis sind Vergleiche wertlos.
• IRQ- und CPU-Isolation für Low-Latency: Exklusive Cores, System-Cores, IRQ-Affinität – aber nur mit sauberem Change-Management.
• Rollback als Runbook: Ein Tuning ohne Rückweg ist im Rechenzentrum nicht produktionsreif.

Fazit: Energieoptimierung ist ein Betriebsdesign, kein Schalter

Energieoptimierung im Rechenzentrum funktioniert nachhaltig, wenn Sie CPU-Freq-Governors, P-States und C-States als Teil eines Betriebsdesigns verstehen: Node-Rollen, Kubernetes-Scheduling, Messmethodik und Rückfallstrategie gehören zusammen. Für allgemeine Workloads ist effizientes Hardware-Scaling oft unkritisch. Für Latenz-kritische Dienste sollten Sie dagegen bewusst mit konservativeren Policies arbeiten, tiefes Idle begrenzen und Isolation (CPU/IRQ) konsequent umsetzen – nicht überall, sondern dort, wo es SLOs wirklich schützt.

Wenn Sie das Thema in Ihrer Umgebung systematisch angehen möchten, planen Sie als Nächstes einen Canary-Pool, definieren Sie Messkriterien (p95/p99 + Residency) und dokumentieren Sie BIOS-/Kernel-Parameter pro Plattform. Damit wird aus „gefühlt schneller“ eine belastbare, betrieblich sichere Entscheidung.