Ungenutzte CPU-Kerne gehen zum Stromsparen in tiefe Energiesparzustände (C-States) und senken ihren Takt. Kommt ein Paket oder ein Timer, brauchen sie Zeit zum Aufwachen und Hochtakten, und die Verarbeitung kleiner Pakete verzögert sich.
Warum Frequenzrichtlinie (Governor) des OS oder Energieeinstellungen im BIOS erlauben tiefe C-States und niedrige Taktfrequenzen → Folge Ein ruhender Kern braucht beim Aufwachen aus einem tiefen Energiesparzustand jedes Mal bis zu mehrere hundert µs, und bei dauerhaft niedrigem Takt wird schon die Tick-Berechnung langsamer → Auf dem Bildschirm Meist kaum spürbar, bei vielen Aufrufen zwischen Servern summiert es sich aber: Input-Lag, gerade wenn wenig los ist. Bei dauerhaft niedrigem Takt geraten die Ticks bei großem Andrang in Verzug: Zeitlupe
Energieeinstellungen im BIOS auf Leistung stellen, OS-Governor auf performance setzen (scaling_governor von cpufreq), auf latenzkritischen Servern tiefe C-States begrenzen (tuned-Profil latency-performance, /dev/cpu_dma_latency von PM QoS, Kernelparameter intel_idle.max_cstate), nach der Änderung Umlaufzeit innerhalb des Rechenzentrums, Jitter der Tick-Zeit und Stromverbrauch gemeinsam vergleichen.
Größenordnungen
Laut der Tabelle des Treibers intel_idle in Linux 6.12 braucht der flache C1-Zustand von Intel-Server-CPUs 1–2 µs zum Aufwachen, der tiefe C6-Zustand 133 µs (Skylake-SP) bis 290 µs (Sapphire Rapids). Einzeln ist das wenig, doch läuft eine Anfrage über mehrere Server, summiert es sich entsprechend. Der Kernel wählt umso tiefere Zustände, je länger die erwartete Leerlaufzeit ist. Deshalb tritt das Problem auf ruhigen Servern, bei denen Pakete nur vereinzelt eintreffen, häufiger auf. Der Governor powersave des generischen cpufreq fixiert die niedrigste erlaubte Frequenz (der gleichnamige Algorithmus von intel_pstate regelt dagegen lastabhängig).
Im Graphen
Von Anfang an dauerhaft hoch · Umlaufzeit innerhalb des Rechenzentrums, Kerntaktfrequenz
Wo nachsehen
Mit cpupower monitor den Anteil der Verweildauer in den C-States und die tatsächliche Frequenz pro Kern prüfen, unter /sys/devices/system/cpu/cpu0/cpuidle/ für jeden state name, latency (Aufwachzeit in µs) und usage ablesen, scaling_governor von cpufreq und mit tuned-adm active das aktive Profil prüfen
Spricht dafür
Bei wenig Last verweilen Kerne lange im tiefsten C-State oder hängen nahe am Mindesttakt fest, mit performance-Governor und flachen C-States sinken Umlaufzeit und Jitter kleiner Anfragen
Spricht dagegen
Unterschied nach der Änderung höchstens einige Dutzend µs: diese Ursache ist vernachlässigbar. Spitzen im Millisekundenbereich: „CPU-Steal (virtuelle Maschine)“ oder eine andere Schicht
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Bei Bare-Metal-Servern im Rechenzentrum sind die Energieeinstellungen im BIOS (Firmware) und die OS-Einstellungen gemeinsam zu prüfen. In der Cloud kann das OS C-States und Taktfrequenz nur bei einigen Instanztypen ändern. Bei AWS steht die Standardeinstellung auf maximaler Leistung, man kann sie also meist unverändert lassen. Das tuned-Profil latency-performance der Red-Hat-Familie setzt den Governor auf performance und erlaubt per PM QoS nur flache C-States. Abgeschaltetes Stromsparen erhöht den Stromverbrauch, deshalb nur auf latenzkritischen Servern anwenden.
Quellen
CPU Idle Time ManagementLinux kernel Jeder Energiesparzustand hat eine Aufwachzeit (exit latency) und eine Mindestverweildauer (target residency), der tiefe Zustand wird passend zur erwarteten Leerlaufzeit gewählt, latency, usage und time pro state in sysfs, tiefe Zustände per PM QoS (/dev/cpu_dma_latency) und intel_idle.max_cstate begrenzen
CPU Performance ScalingLinux kernel Governor mit scaling_governor prüfen und ändern, performance fordert die höchste erlaubte Frequenz an, powersave die niedrigste
intel_pstate CPU Performance Scaling DriverLinux kernel Der Algorithmus powersave von intel_pstate regelt im Unterschied zum generischen powersave-Governor lastabhängig (ähnlich wie schedutil und ondemand)
Chapter 2. Getting started with TuneDRed Hat Das Profil latency-performance schaltet Stromsparfunktionen ab, setzt den Governor auf performance und erlaubt per PM QoS nur flache C-States, aktives Profil mit tuned-adm active prüfen
Processor state control for Amazon EC2 Linux instancesAWS Nur bei einigen Instanztypen kann das OS C-States und P-States steuern und zur Latenzsenkung ändern, die Standardeinstellung ist maximale Leistung und passt für die meisten Workloads, Graviton hat eine feste Frequenz, die das OS nicht steuert