Türkei (Türkisch)
Germany (German)
Worldwide (English)
Linux-Dokumentation definiert Steal als unfreiwillige Wartezeit des Gasts; sar beschreibt %steal als Wartezeit, während der Hypervisor andere vCPU bedient.
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
%steal auf Linux-VPS mit top, mpstat, sar und /proc/stat messen und CPU-Contention von Anwendungsengpässen trennen.
Linux-Dokumentation definiert Steal als unfreiwillige Wartezeit des Gasts; sar beschreibt %steal als Wartezeit, während der Hypervisor andere vCPU bedient.
Steal Time ist ein Signal des Virtualisierungs-Schedulers und hat auf Bare Metal nicht dieselbe Bedeutung.
Der Gast möchte rechnen, aber der Hypervisor vergibt physische CPU-Zeit an eine andere VM. Das kann als %steal erscheinen, obwohl die Anwendungs-CPU niedrig aussieht.
Nicht jede Langsamkeit ist Steal. Iowait, Memory Pressure, Swap, Netzwerk, DB-Locks, Worker-Queues und DNS können ähnlich wirken.
In top ist `st` ein Schnellcheck. `mpstat -P ALL 1` zeigt Steal pro CPU, `sar -u 1 60` als Zeitreihe. `/proc/stat` enthält den Rohzähler.
topmpstat -P ALL 1 20sar -u 1 60grep '^cpu ' /proc/statEin einzelner Spike reicht nicht. 5-15-Minuten-Messungen unter gleichem Workload zu verschiedenen Zeiten sammeln. Wiederkehrende Erhöhungen zu Stoßzeiten sprechen stärker für Host-Contention.
Einige Provider veröffentlichen Richtwerte, aber es gibt keinen universellen Grenzwert. Latenzsensitive Anwendungen können schon kleinere Werte spüren.
CPU-Quota kann drosseln, wenn das eigene Limit erreicht ist; Steal ist unfreiwilliges Warten durch Hypervisor-Scheduling. Symptome ähneln sich, Ursachen nicht.
Bei Container-VPS sind cgroup-Throttling-Metriken wichtiger; bei Full VMs häufig Steal und Guest-Scheduler.
Wiederholbaren CPU-Test, Anwendungs-Latenz und Steal gleichzeitig erfassen. Verschlechtern sich Benchmark und Response mit steigender Steal Time bei gleichem Workload, wird Host-Contention wahrscheinlicher.
sysbench cpu --threads=1 --time=30 runsysbench cpu --threads=$(nproc) --time=30 runDatum/Uhrzeit, Zeitzone, mpstat/sar, CPU-Modell/vCPU, Workload und Response-Daten senden. Messbare Daten helfen mehr als 'Server ist langsam'.
| Metrik | Bei hohem Wert |
|---|---|
| %steal | Hypervisor-Scheduling/Contention |
| %iowait | Storage-Wartezeit |
| Hohe Load, niedrige CPU | I/O oder blockierte Tasks |
| Swap steigt | Memory Pressure |
Kaufentscheidungen nicht anhand eines einzelnen Benchmarks, Port-Labels oder CPU-Markennamens treffen. Tests zu verschiedenen Zeiten wiederholen, keine destruktiven Storage-Tests auf Produktionsdaten durchführen und Ressourcen-/Fair-Use-Policies schriftlich prüfen.
Niedrig und stabil ist besser; kleine kurzfristige Werte können auftreten. Mit Workload-Latenz zusammen bewerten.
Sie kann Last reduzieren, aber echte Host-Contention erfordert Provider-seitige Änderungen.
Software, Parallelität, Storage-/DB-Last und Zielregion angeben; Serverklasse nach realem Engpass statt nur RAM/Core wählen.