CPU Steal Time erklärt (und wann dedizierte Hardware sinnvoll ist)

Steal Time ist kein allgemeiner „mein Server ist langsam“-Zähler. Es ist keine Disk-Latenz. Es ist keine Netzwerk-Latenz. Und es ist kein Urteil über deinen Code.

Ein häufiger Fehler ist, Steal Time mit I/O Wait zu verwechseln.

In mpstat bedeutet %iowait:

• CPU-Leerlaufzeit, während das System auf ausstehende Disk-I/O wartet.

 

In mpstat bedeutet %steal:

• Die vCPU wartet unfreiwillig, weil der Hypervisor anderweitig beschäftigt ist.

 

Wer das vermischt, sucht an der falschen Stelle nach der Lösung.

Option 1: top (schnellster Check)
Ausführen:
top

Sieh dir die CPU-Zusammenfassung an.
Fühlen sich Builds, Request-Verarbeitung oder Queues langsam an und steigt st gleichzeitig, ist das ein Signal.
Hinweis: top dokumentiert selbst, dass das st-Feld je nach Kernel-Version fehlen kann. Ist es nicht vorhanden, nutze mpstat oder vmstat.

Option 2: mpstat (am besten für Messreihen)
Wenn sysstat installiert ist:
mpstat -P ALL 1 60

Das liefert pro CPU jede Sekunde Samples, inklusive %steal und %iowait.

Kürzer:
mpstat -P ALL 1 10

Option 3: vmstat (schneller Überblick)
Ausführen:
vmstat 1 10

In vmstat findest du unter CPU:

• st: time stolen from a virtual machine.

Option 4: Quelle prüfen über /proc/stat
Wenn du Tool-Interpretation ausschließen willst, prüfe /proc/stat.

Die cpu-Zeile enthält mehrere Zähler, darunter:

• steal: stolen time while running in a virtualized environment.

 

Viele Tools lesen diese Daten direkt aus.

Steal Time wird erst dann wirklich nützlich, wenn du sie mit Symptomen korrelierst.

Muster 1: Latenzspitzen fallen mit Steal-Spitzen zusammen
Was du siehst:

• p95- oder p99-Latenz springt für Sekunden bis Minuten
• Queue-Zeiten steigen
• Requests schlagen meist nicht fehl, kommen aber zu spät

 

Was du tust:

• mpstat -P ALL 1 60 während der langsamen Phase erfassen
• Timestamps mit deiner Latenzgrafik vergleichen

 

Steigen Latenz und %steal gemeinsam, liegt die Ursache sehr wahrscheinlich vor deinem Code.

Muster 2: Load Average steigt, aber die App „bekommt keine CPU“
Hier bleiben viele Teams hängen:

• Load Average steigt
• Latenz steigt
• User-CPU steigt nicht wie erwartet
• Steal Time steigt

 

Tasks sind lauffähig, aber die VM wartet auf echte CPU-Zeit.

Zur Bestätigung Scheduler-Druck prüfen:
sar -q 1 10

sar -q zeigt runq-sz, die Länge der Run Queue. Das ist ein hilfreiches Signal für Runnable-Pressure bei Scheduling-Problemen.

Muster 3: Anhaltende Steal Time bei normaler Last
Peaks happen. Short host events happen.

Was Produkte wirklich trifft, ist reproduzierbare Steal Time bei normaler Workload, vor allem wenn sie mit Tail-Latenz zusammenfällt.
Red Hat formuliert es klar: Große Mengen Steal Time deuten auf CPU-Contention hin und reduzieren die Performance des Guests.

Dieser Abschnitt ist bewusst hier. Überspringst du ihn, wird deine Standardreaktion „dedicated, bis das Gegenteil bewiesen ist“. Das ist keine Ingenieursarbeit.
Nutze diese Ausschlussliste.

1) %steal ist nahe null? Prüfe CPU-Throttling-Modelle

Ein klassisches Beispiel sind burstable CPU-Credit-Modelle. Sind die Credits aufgebraucht, fällt die Instanz auf ihr Baseline-Verhalten zurück. Das wirkt wie „zufällige Verlangsamung“ bei niedriger oder null Steal Time.

2) Container im Einsatz? Erst cgroup-CPU-Throttling prüfen

In Kubernetes werden CPU-Limits durch Throttling durchgesetzt. Ein Container kann langsam sein, weil er sein CPU-Limit erreicht, selbst wenn die VM insgesamt kaum Steal Time zeigt.

3) %iowait hoch? Dann bist du storage-gebunden

Hoher %iowait bei niedrigem %steal deutet auf:

• disk
• filesystem
• database I/O
• storage contention

 

Steal Time ist keine Storage-Metrik. Behandelst du sie so, verlierst du Tage.

4) CPU-Placement-Probleme? NUMA und Pinning prüfen

NUMA-Placement kann reale Performanceverluste verursachen. Wenn du vCPU-Pinning nutzt, muss NUMA-Tuning berücksichtigt werden. Sonst erzeugst du unnötige Misses und unvorhersehbares Verhalten.
Das ist relevanter, wenn du den Host kontrollierst, kann aber auch in Managed-Umgebungen eine Rolle spielen.

5) Fallen Slowdowns mit Wartung zusammen? Live-Migration prüfen

Live-Migration existiert und kann kurzfristiges Jitter erzeugen. Dabei läuft der Guest weiter, während Speicher auf einen anderen Host übertragen wird. Nicht vermuten. Zeiten korrelieren.

6) Ändert sich die CPU-Frequenz? Dann ändert sich Performance

CPU-Frequency-Scaling ist real. Höhere Frequenz bedeutet meist mehr Instruktionen pro Zeiteinheit bei höherem Energieverbrauch. Governor und Scaling-Algorithmen passen das Verhalten an die Last an.
Kommt häufiger auf eigener Hardware vor, ist aber messbar und gehört ins Gesamtbild.

Der praxisrelevante Teil.

Schritt 1: Korrelation nachweisen

Während einer langsamen Phase erfassen:

• mpstat für %steal und %iowait
• sar -q für Run-Queue-Druck
• p95- und p99-Latenz aus APM oder Logs
• Timestamps von Deployments und Background-Jobs

Kommandos:

mpstat -P ALL 1 60
sar -q 1 60
vmstat 1 60

Passen Latenzspitzen und Steal-Spitzen zusammen, hast du Beweise für CPU-Scheduling-Contention upstream. Steigt stattdessen %iowait, hör auf über dedicated CPUs zu sprechen. Dann hast du ein I/O-Problem.

Schritt 2: Entscheiden, ob das innerhalb von VPS lösbar ist

Fragen an den Provider:

• Könnt ihr mich auf einen anderen Host verschieben?
• Bietet ihr Dedicated-vCPU- oder Low-Oversubscription-Pläne an?
• Könnt ihr bestätigen, ob CPU-Overcommit auf dieser Hostklasse genutzt wird?

 

Kann der Provider das nicht beantworten, ist das bereits eine Antwort.

Schritt 3: Eine pragmatische Eskalationsregel nutzen

Es gibt keinen universellen Grenzwert. Aber du brauchst keine perfekte Messung, um zu handeln.
Eine häufig zitierte Faustregel:

• Liegt Steal Time über 10 Prozent für 20 Minuten, läuft die VM wahrscheinlich langsamer als nötig.

 

Das ist ein Eskalationssignal, kein Naturgesetz. Bei latenzsensiblen Systemen greifst du oft früher ein. Nicht weil die CPU „voll“ ist, sondern weil Tail-Latenz steigt.

Schritt 4: Wissen, was sich mit Dedicated ändert

Dedizierte Hardware entfernt eine große Variable:

• gemeinsames CPU-Scheduling mit fremden Workloads.

 

War Steal Time die Ursache, sollte sie unter vergleichbarer Last nahezu auf null fallen. Aber sei präzise. Steal Time ist eine virtuelle CPU-Metrik. Installierst du selbst einen Hypervisor auf dedizierter Hardware und überbuchst ihn, kannst du Steal Time erneut erzeugen. Dedicated entfernt den noisy neighbor. Es entfernt keine schlechte Kapazitätsplanung.

Bewerte Erfolg nicht nach Gefühl. Bewerte ihn wie ein Engineering-Team.

Wenn Steal Time die Ursache war, sieht Erfolg so aus:

• %steal bleibt nahe null bei gleicher Last
• p95- und p99-Latenz stabilisieren sich
• Build-Zeiten werden vorhersagbar
• Incident-Reports enthalten nicht mehr „nicht reproduzierbar“ oder „hat sich von selbst erledigt“

 

Bleibt Steal niedrig, aber Latenz instabil, hast du nun Beweise, dass der Engpass woanders liegt. Häufig I/O, Throttling oder Applikations-Contention.
Auch das ist ein Gewinn. Das Problem wird eingegrenzt.