CPU-Governor und Frequency-Scaling-Tuning fuer latenzkritische Server

1. Warum der CPU-Governor fuer Web-Latenz relevant ist

Moderne CPUs takten sich nicht dauerhaft mit ihrer maximalen Frequenz, sondern regeln die Taktrate dynamisch abhaengig von der aktuellen Last, um Energie zu sparen. Verantwortlich dafuer ist der CPU-Governor, eine Kernel-Komponente, die entscheidet, wie schnell und wie aggressiv die Taktfrequenz an die Last angepasst wird. Auf Desktop-Systemen ist dieses Verhalten meist erwuenscht, auf einem latenzkritischen Magento-Webserver kann der falsche CPU-Governor jedoch dazu fuehren, dass jede eintreffende Anfrage zunaechst auf eine hochlaufende Taktfrequenz warten muss.

Besonders bei PHP-FPM-Workloads mit vielen kurzen, sprunghaften Anfragen zeigt sich dieser Effekt deutlich: Ein Worker-Prozess, der laengere Zeit im Leerlauf war, laeuft unter einem konservativen CPU-Governor zunaechst mit reduzierter Taktfrequenz, und die Hochskalierung auf die volle Frequenz dauert je nach Hardware und Governor-Einstellung mehrere Millisekunden, was sich direkt in der Time to First Byte niederschlaegt.

Dieser Artikel zeigt, welche CPU-Governor-Typen der Linux-Kernel anbietet, wie die aktuelle Konfiguration ermittelt und dauerhaft angepasst wird, und wie C-States sowie Turbo Boost zusammen mit dem Governor die tatsaechliche Reaktionszeit eines Magento-Servers beeinflussen.

2. cpufreq-Grundlagen: Taktfrequenz, Skalierung und Governor

Das cpufreq-Subsystem des Kernels stellt die Schnittstelle bereit, ueber die die Taktfrequenz jedes einzelnen CPU-Kerns unabhaengig gesteuert werden kann. Jede CPU unterstuetzt dabei einen Bereich zwischen einer minimalen und einer maximalen Frequenz, und der CPU-Governor entscheidet innerhalb dieses Bereichs kontinuierlich, welche Frequenz aktuell angemessen ist. Diese Entscheidung basiert auf verschiedenen Heuristiken, abhaengig vom gewaehlten Governor-Typ, und wird typischerweise mehrmals pro Sekunde neu getroffen.

Der Wechsel zwischen Frequenzstufen ist nicht instantan. Je nach Hardware-Generation dauert eine vollstaendige Hochskalierung von der Minimal- zur Maximalfrequenz zwischen wenigen Mikrosekunden auf modernen Intel- und AMD-Plattformen mit Hardware-P-States bis zu mehreren Millisekunden auf aelterer Hardware oder in bestimmten virtualisierten Umgebungen. Fuer einen einzelnen HTTP-Request mag das vernachlaessigbar klingen, bei tausenden Requests pro Sekunde summiert sich diese Verzoegerung aber zu einer messbaren Verschlechterung der P99-Latenz.

3. Die wichtigsten Governor-Typen im Detail

Der Governor powersave haelt die CPU standardmaessig auf der niedrigsten verfuegbaren Frequenz und erhoeht sie nur bei tatsaechlich anhaltender Last, was maximale Energieeffizienz bietet, aber die hoechste Reaktionslatenz bei sprunghafter Last verursacht. Der Governor performance haelt die CPU dagegen dauerhaft auf der maximal moeglichen Frequenz, unabhaengig von der aktuellen Auslastung, was jede Reaktionsverzoegerung eliminiert, aber den Energieverbrauch und die Waermeentwicklung deutlich erhoeht.

Der modernere Governor schedutil, seit einigen Kernel-Versionen der Standard auf vielen Distributionen, arbeitet eng mit dem CFS-Scheduler zusammen und reagiert deutlich schneller auf ploetzliche Lastspitzen als aeltere Governor wie ondemand, weil er direkt auf Scheduler-Informationen zugreift statt periodisch die Auslastung abzufragen. Fuer viele latenzkritische Web-Workloads ist schedutil inzwischen ein guter Kompromiss zwischen Energieeffizienz und Reaktionsgeschwindigkeit, erreicht aber nicht ganz die konstante Nullverzoegerung von performance.

4. Aktuellen Governor und Taktfrequenz ermitteln

Bevor ein CPU-Governor geaendert wird, sollte der aktuelle Zustand bekannt sein. Das Tool cpupower frequency-info zeigt fuer jeden CPU-Kern den aktuell aktiven Governor, die unterstuetzten Frequenzstufen und die tatsaechlich gemessene aktuelle Taktfrequenz. Auf Systemen ohne cpupower liefern die virtuellen Dateien unter /sys/devices/system/cpu/cpu*/cpufreq/ dieselben Informationen direkt.

Wichtig ist, diese Werte unter realistischer Last zu pruefen, nicht nur im Leerlauf. Ein Server, der im Leerlauf korrekt mit performance konfiguriert erscheint, kann unter virtualisierten Umgebungen trotzdem effektiv gedrosselt werden, wenn der Hypervisor selbst eigene Frequenz- oder CPU-Limits durchsetzt, die vom Gast-Betriebssystem aus nicht sichtbar sind.

# Show current governor, min/max frequency, and live clock speed per core
cpupower frequency-info

# Same information directly from sysfs, per core
for cpu in /sys/devices/system/cpu/cpu[0-9]*; do
  echo "$cpu: $(cat $cpu/cpufreq/scaling_governor) @ $(cat $cpu/cpufreq/scaling_cur_freq) kHz"
done

# List all governors supported by the current driver
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

5. Governor dauerhaft auf performance oder schedutil setzen

Ein Wechsel ueber cpupower frequency-set -g performance wirkt sofort, geht aber nach einem Neustart verloren, sofern keine Persistierung eingerichtet wurde. Fuer produktive Magento-Server empfiehlt sich ein systemd-Service, der den gewuenschten CPU-Governor bei jedem Boot automatisch erneut setzt, analog zur bekannten Problematik bei Transparent Huge Pages, wo eine einmalige manuelle Aenderung ebenfalls nicht persistent ist.

Auf vielen Cloud-Plattformen und in Container-Umgebungen ist der Zugriff auf cpufreq eingeschraenkt oder wird vom Hypervisor komplett abstrahiert, sodass eine Governor-Aenderung dort wirkungslos bleibt. In diesem Fall lohnt sich stattdessen ein Blick auf die Performance-Optionen des jeweiligen Cloud-Anbieters, etwa dedizierte, nicht geteilte CPU-Instanztypen, die konstant hohe Taktfrequenzen garantieren, statt auf Governor-Ebene selbst optimieren zu koennen.

# Apply immediately to all cores
cpupower frequency-set -g performance

# Verify the change took effect
cpupower frequency-info | grep "governor"

# /etc/systemd/system/cpu-governor.service
[Unit]
Description=Set CPU governor to performance at boot
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower frequency-set -g performance
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

# Enable with: systemctl daemon-reload && systemctl enable --now cpu-governor.service

6. C-States: Idle-Tiefe und Aufwachlatenz

Neben der Taktfrequenz selbst beeinflussen sogenannte C-States, wie tief ein CPU-Kern im Leerlauf schlaeft. Ein hoeherer C-State spart mehr Energie, benoetigt aber laenger, um den Kern wieder vollstaendig einsatzbereit zu machen, wenn eine neue Anfrage eintrifft. Diese Aufwachlatenz addiert sich zur reinen CPU-Governor-Hochskalierung und kann auf manchen Serverplattformen im Bereich mehrerer Mikrosekunden bis niedriger Millisekunden liegen.

Fuer maximal latenzkritische Workloads laesst sich die maximal erlaubte C-State-Tiefe ueber den Kernel-Parameter intel_idle.max_cstate oder das Tool cpupower idle-set begrenzen, sodass Kerne im Leerlauf nur flach schlafen und dadurch schneller reagieren, allerdings auf Kosten eines hoeheren Grundverbrauchs auch bei fehlender Last. Diese Massnahme lohnt sich nur, wenn Governor-Tuning allein nicht ausreicht und die verbleibende Latenz nachweislich durch tiefe C-States verursacht wird.

# List available C-states and their exit latency (microseconds)
cpupower idle-info

# Disable the deepest C-state to reduce wake-up latency
cpupower idle-set -d 3

7. Turbo Boost und thermische Grenzen verstehen

Turbo Boost, respektive AMD Precision Boost, erlaubt einer CPU, kurzzeitig ueber ihre nominale Maximalfrequenz hinaus zu takten, solange thermische und Stromgrenzen das zulassen. In Kombination mit dem performance-CPU-Governor profitieren einzelne, kurzzeitig stark ausgelastete Kerne von dieser zusaetzlichen Frequenz, was besonders bei einzelnen langsamen PHP-Requests, die kurzzeitig maximale Rechenleistung brauchen, spuerbar wird.

Wichtig zu verstehen ist, dass Turbo Boost keine dauerhafte Garantie ist. Bei anhaltend hoher Auslastung ueber alle Kerne hinweg reduziert die CPU die Turbo-Frequenz automatisch, um innerhalb ihrer thermischen Grenzen zu bleiben. Ein Server, der durchgaengig mit hoher paralleler PHP-FPM-Last laeuft, profitiert deshalb weniger von Turbo Boost als ein Server mit sprunghafter, ungleichmaessig verteilter Last, bei dem einzelne Kerne zwischenzeitlich frei bleiben.

8. Typische Fehler beim Governor-Tuning

Der haeufigste Fehler ist, den CPU-Governor nur temporaer per Kommandozeile zu setzen, ohne eine Persistierung fuer den naechsten Neustart einzurichten. Nach einem Kernel-Update oder Server-Reboot faellt der Server dann unbemerkt auf den Standard-Governor zurueck, oft powersave oder ondemand, und die urspruenglich behobene Latenzproblematik kehrt zurueck, ohne dass eine offensichtliche Ursache im Monitoring auftaucht.

Ein zweiter Fehler ist, den CPU-Governor auf virtualisierten Instanzen zu aendern, ohne zu pruefen, ob der Hypervisor die Aenderung ueberhaupt durchreicht. Auf vielen geteilten Cloud-Instanzen hat die Governor-Einstellung des Gastsystems keinerlei Effekt, weil der Host die tatsaechliche Taktfrequenz zentral verwaltet. Ein dritter Fehler ist, performance blind auf jeden Server anzuwenden, ohne die zusaetzliche Energie- und Waermebelastung fuer Server mit vielen physischen Kernen zu beruecksichtigen, die im Dauerbetrieb messbar hoehere Betriebskosten verursachen kann.

9. Governor-Strategien im Vergleich

Die folgende Tabelle stellt die relevanten CPU-Governor-Optionen fuer latenzkritische Server gegenueber.

Fuer die meisten latenzkritischen Magento-Produktivserver ist entweder performance oder ein aktueller schedutil-Governor die richtige Wahl. Fuer Entwicklungs- und Staging-Umgebungen mit geringerer Priorisierung von Latenz kann der energieeffizientere ondemand- oder powersave-Governor sinnvoller sein, um Betriebskosten zu senken.

10. Zusammenfassung

Der CPU-Governor entscheidet, wie schnell ein Server auf sprunghafte Last reagiert, und ist auf latenzkritischen Magento-Webservern haeufig ein uebersehener Hebel. powersave spart Energie auf Kosten der Reaktionszeit, performance eliminiert Frequenzverzoegerungen vollstaendig, und schedutil bietet inzwischen einen guten Kompromiss durch enge Kopplung an den Scheduler. Mit cpupower frequency-info laesst sich der aktuelle Zustand ermitteln, mit cpupower frequency-set und einem systemd-Service laesst er sich reboot-fest anpassen.

C-States und Turbo Boost ergaenzen die reine CPU-Governor-Wahl: flachere C-States reduzieren Aufwachlatenz auf Kosten hoeheren Grundverbrauchs, Turbo Boost liefert kurzzeitige Zusatzleistung, ist aber keine dauerhafte Garantie unter durchgaengig hoher Last. Fuer produktive Latenz-kritische Server ist die Kombination aus performance oder schedutil mit reduzierter C-State-Tiefe meist die robusteste Wahl.

11. FAQ: CPU-Governor und Frequency-Scaling-Tuning