Steal-Time messen: Wie viel Rechenzeit Ihr netcup-VPS verliert

Ein netcup-VPS teilt sich die Prozessoren des Hosts mit anderen Kunden, ein Root-Server hat laut netcup dedizierte Kerne. Ob Ihr VPS unter seinen Nachbarn leidet, zeigt ein einziger Wert: die Steal-Time. Das ist die Zeit, in der Ihre virtuelle CPU rechnen wollte, der Hypervisor sie aber nicht rechnen ließ. Diese Anleitung zeigt Schritt für Schritt, wie Sie die Steal-Time messen, unter Last prüfen, dauerhaft aufzeichnen und richtig deuten. Unsere Messwerte stammen von einem VPS 500 G12.5 mit 2 vCore in Nürnberg am Abend des 03.11.2026.

Dies ist Teil 10 der Reihe „netcup Spezial“.

Voraussetzungen

• netcup-VPS oder Root-Server mit Linux, im Test ein VPS 500 G12.5 (2 vCore, 4 GB RAM) mit Ubuntu 24.04
• SSH-Zugang als root
• Ein Zeitfenster, in dem zwei Minuten Volllast nicht stören
• Etwa 20 Minuten, für die Daueraufzeichnung einige Tage

Schritt 1: Was Steal-Time bedeutet

Auf einem Host laufen viele virtuelle Maschinen. Will Ihre virtuelle CPU rechnen, während der Hypervisor den physischen Kern gerade einer anderen Maschine gibt, wartet sie. Diese Wartezeit zählt Linux als Steal-Time. Sie ist kein Fehler Ihres Systems, Sie können sie im Gast nicht senken. Sie zeigt aber, wie viel Rechenzeit Ihnen fehlt.

netcup unterscheidet in seiner Server-Übersicht ausdrücklich: VPS haben keine dedizierten CPU-Kerne, Root-Server schon. Bei einem VPS ist etwas Steal-Time deshalb normal. Entscheidend ist, wie viel und wie oft.

Verifizieren: Sie wissen, ob Ihr Server ein VPS oder ein Root-Server ist.

Schritt 2: Werkzeuge installieren

Für die Messung reichen die Pakete sysstat für mpstat und sar sowie stress-ng für die Last. Wer zusätzlich die Rechenleistung vergleichen möchte, nimmt sysbench dazu:

apt-get install -y sysstat stress-ng sysbench

Im Test kamen sysstat 12.6.1, stress-ng 0.17.06 und sysbench 1.0.20 aus den Paketquellen von Ubuntu 24.04.

Verifizieren: mpstat -V zeigt die Version von sysstat.

Schritt 3: Messen im Leerlauf

Messen Sie zuerst, wenn der Server wenig zu tun hat, über eine Minute in Abständen von fünf Sekunden:

mpstat 5 12

Die letzte Zeile zeigt den Durchschnitt. Auf unserem VPS waren die wichtigsten Spalten:

Messung	%usr	%sys	%steal	%idle
Leerlauf, Durchschnitt über 60 s	2,45	2,03	0,01	95,38

Im Leerlauf sagt die Steal-Time wenig. Wer kaum rechnen will, dem kann auch kaum etwas weggenommen werden. Der eigentliche Test kommt im nächsten Schritt.

Verifizieren: mpstat zeigt eine Spalte %steal mit Werten.

Schritt 4: Messen unter Volllast

Erzeugen Sie auf allen Kernen Volllast und messen Sie gleichzeitig. Wir haben stress-ng für gut zwei Minuten auf beide vCores gesetzt und dabei zwei Minuten lang gemessen:

stress-ng --cpu 2 --timeout 125s &
sleep 3
mpstat 5 24

Passen Sie --cpu an die Zahl Ihrer vCores an. Das Ergebnis auf unserem VPS:

Messung	%usr	%sys	%steal	%idle
Volllast, Durchschnitt über 120 s	96,20	2,39	1,37	0,01
Einzelwert um 23:13:03	97,04	1,64	1,31	0,00
Einzelwert um 23:13:08	96,50	2,08	1,42	0,00

Unter Volllast fehlten unserem VPS also rund 1,4 Prozent der Rechenzeit. Das ist für einen Server mit geteilten Kernen ein niedriger Wert. Den Zähler können Sie auch direkt im Kernel ablesen. Die achte Zahl in der Zeile cpu von /proc/stat ist die gesamte Steal-Time seit dem Start in Hundertstelsekunden. Bei uns stieg sie von Beginn der Leerlaufmessung bis nach dem sysbench-Lauf in Schritt 8 von 16 auf 479, also um rund 4,6 Sekunden, summiert über beide vCores.

grep "^cpu " /proc/stat

Verifizieren: Während der Last zeigt %idle nahe 0. Erst dann ist der Wert für %steal aussagekräftig.

Schritt 5: Schnelle Blicke mit top und vmstat

Für einen kurzen Blick zwischendurch reichen Bordmittel. In top steht die Steal-Time in der Zeile %Cpu(s) als letzter Wert st, in vmstat in der Spalte st:

vmstat 1 5

Bei uns zeigte die Spalte st nach dem Lasttest Werte von 0 und 1. vmstat rundet auf ganze Prozent und eignet sich deshalb nur für grobe Blicke. Für Vergleiche über die Zeit nehmen Sie mpstat oder sar.

Verifizieren: Sie finden in top den Wert st und in vmstat die gleichnamige Spalte.

Schritt 6: Dauerhaft aufzeichnen

Eine Messung am Abend sagt nichts über den Mittag. Lassen Sie sysstat die Werte deshalb ständig mitschreiben. Unter Ubuntu 24.04 war die Aufzeichnung nach der Installation ausgeschaltet:

ENABLED="false"

So schalten Sie sie ein:

sed -i 's/^ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
systemctl enable --now sysstat sysstat-collect.timer
grep ^ENABLED /etc/default/sysstat

Die letzte Zeile muss ENABLED="true" zeigen, sonst zeichnet sysstat ohne Fehlermeldung nichts auf. Danach lief der Zeitgeber sysstat-collect.timer und plante die nächste Aufzeichnung für die volle Zehn-Minuten-Marke. Schon nach der ersten Aufzeichnung zeigt sar -u die gespeicherten Werte des Tages. Bei uns sah das um 23:31 Uhr so aus, gekürzt um die Kopfzeile:

23:17:20     LINUX RESTART	(2 CPU)

23:20:16        CPU     %user     %nice   %system   %iowait    %steal     %idle
23:30:21        all     14,97      0,00      2,95      0,10      0,18     81,80

Die Zeile LINUX RESTART markiert den Start der Aufzeichnung, jede weitere Zeile fasst zehn Minuten zusammen. Mit sar -u -f /var/log/sysstat/saTT lesen Sie einen früheren Tag, wobei TT für den Tag im Monat steht. Live funktioniert sar ebenfalls:

sar -u 2 3

23:17:11        CPU     %user     %nice   %system   %iowait    %steal     %idle
23:17:13        all      3,02      0,00      2,26      0,00      0,00     94,72

Die Ausgabe ist auf die Spaltenköpfe und die erste Messzeile gekürzt.

Verifizieren: systemctl is-active sysstat-collect.timer meldet active.

Schritt 7: Die Werte richtig deuten

Eine feste Grenze haben wir bei netcup nicht gefunden. Als Faustregel für die Praxis:

• Werte von wenigen Prozent unter Last, wie bei uns, sind bei geteilten Kernen unauffällig.
• Kurze Spitzen sind normal, wenn Nachbarn gleichzeitig rechnen.
• Liegt die Steal-Time über Stunden deutlich im zweistelligen Bereich, verlieren Ihre Dienste spürbar Rechenzeit.
• Steigen die Werte über mehrere Tage regelmäßig über wenige Prozent, beobachten Sie genauer.

Bei dauerhaft hohen Werten sammeln Sie die Aufzeichnungen von sar und wenden sich an den netcup-Support. Ist Ihr Dienst auf gleichmäßige Rechenleistung angewiesen, etwa ein Spieleserver oder eine Datenbank mit vielen Anfragen, lohnt ein Root-Server, der laut netcup dedizierte Kerne hat. Die Auslastung im SCP ergänzt diese Werte, siehe unsere Anleitung zu den SCP-Statistiken.

Verifizieren: Sie haben Werte unter Last aus mehreren Tageszeiten, bevor Sie urteilen.

Schritt 8: Rechenleistung vergleichen

Die Steal-Time zeigt, wie viel fehlt, nicht, wie schnell der Server ist. Für einen Vergleich zwischen Servern oder Tageszeiten hilft ein einfacher Benchmark:

sysbench cpu --threads=2 --time=60 run | grep -E "events per second|total number|95th"

    events per second:  2651.49
    total number of events:              159093
         95th percentile:                        0.73

Der Wert gilt nur für diesen Server und diesen Zeitpunkt. Vergleichbar wird er, wenn Sie denselben Befehl auf einem anderen Server oder zu einer anderen Uhrzeit ausführen. Sinkt der Wert deutlich, während die Steal-Time steigt, haben Sie einen guten Beleg für ein Gespräch mit dem Support.

Verifizieren: Sie haben einen Ausgangswert von sysbench notiert.

Schritt 9: Eine einfache Warnung einrichten

Wer nicht täglich in sar schauen möchte, lässt sich warnen. Dieses kleine Skript misst die Steal-Time über 60 Sekunden direkt aus /proc/stat und schreibt eine Meldung ins Systemlog, wenn eine Grenze überschritten ist. Speichern Sie es als /usr/local/bin/steal-check und machen Sie es mit chmod +x ausführbar:

#!/bin/bash
# Steal-Time über 60 Sekunden messen und bei Überschreitung melden
GRENZE=${1:-10}
read -r _ u1 n1 s1 i1 w1 q1 sq1 st1 _ < /proc/stat
sleep 60
read -r _ u2 n2 s2 i2 w2 q2 sq2 st2 _ < /proc/stat
gesamt=$(( (u2+n2+s2+i2+w2+q2+sq2+st2) - (u1+n1+s1+i1+w1+q1+sq1+st1) ))
steal=$(( st2 - st1 ))
prozent=$(awk -v s=$steal -v g=$gesamt 'BEGIN{printf "%.2f", (g>0)?100*s/g:0}')
echo "$(date '+%F %T') Steal-Time ${prozent} %"
awk -v p=$prozent -v g=$GRENZE 'BEGIN{exit !(p>g)}' && logger -t steal-check "Steal-Time ${prozent} % über Grenze ${GRENZE} %"
exit 0

Im Test meldete das Skript im Leerlauf 0,01 Prozent. Unter Volllast und mit einer absichtlich niedrigen Grenze von 0,5 Prozent schrieb es den erwarteten Eintrag ins Journal:

2026-11-03 23:22:50 Steal-Time 1.37 %
steal-check[21036]: Steal-Time 1.37 % über Grenze 0.5 %

Die zweite Zeile stammt aus journalctl -t steal-check, gekürzt um Zeitstempel und Hostnamen. Lassen Sie das Skript regelmäßig mit einer sinnvollen Grenze laufen, etwa steal-check 10, und geben Sie die Grenze mit Punkt an, nicht mit Komma. Lassen Sie dann Ihr Monitoring nach dem Kennzeichen steal-check im Log suchen. Beachten Sie, dass eine Messung im Leerlauf kaum etwas zeigt. Das Skript eignet sich vor allem für Server, die regelmäßig Last haben.

Verifizieren: steal-check 0.5 schreibt unter Last einen Eintrag, den journalctl -t steal-check anzeigt.

Typische Fehler

Symptom	Ursache und Lösung
%steal immer 0	Im Leerlauf gemessen. Unter Last messen.
sar -u zeigt keine älteren Werte	Aufzeichnung ausgeschaltet. ENABLED="true" setzen und den Zeitgeber aktivieren.
Werte schwanken stark	Momentaufnahmen. Über Tage aufzeichnen und Durchschnitte vergleichen.
Server langsam, aber Steal-Time niedrig	Ursache liegt woanders, etwa Arbeitsspeicher, Festplatte oder Anwendung.

Häufige Fragen

Hilft mehr vCPU gegen Steal-Time?

Mehr vCPU geben Ihnen mehr Rechenzeit, die Steal-Time je Kern hängt aber vom Host und den Nachbarn ab. Bei gleichmäßigem Bedarf sind dedizierte Kerne die eigentliche Lösung.

Belastet der Lasttest andere Kunden?

Ein wenig, denn bei geteilten Kernen konkurriert Ihre Last mit den Nachbarn. Zwei Minuten sind unkritisch, wiederholen Sie den Test aber nicht im Dauerbetrieb.

Zeigt das SCP die Steal-Time?

Der Reiter Statistiken zeigte bei uns für CPU0 und CPU1 je eine Kurve in OP/s, wahlweise für 6 Stunden bis 31 Tage. Eine eigene Anzeige der Steal-Time gab es dort nicht, messen Sie sie deshalb im System.

Fazit

Die Steal-Time zeigt, wie viel Rechenzeit Ihnen der Host vorenthält. Gemessen unter Last und über Tage aufgezeichnet zeigt er, ob Ihnen der Host genug Rechenzeit lässt. Unser VPS 500 G12.5 verlor unter Volllast rund 1,4 Prozent, ein guter Wert für geteilte Kerne. Wer dauerhaft deutlich mehr sieht, hat mit den Aufzeichnungen von sar eine solide Grundlage für den Support oder den Wechsel auf einen Root-Server.

Weiterführende Anleitungen und Quellen

• netcup SCP-Statistiken lesen
• Teil 4: SCP-Einstellungen und CPU-Topologie
• Teil 1: Server umziehen
• Ubuntu-Server mit Docker als Grundlage
• netcup: Server-Varianten im Vergleich
• sysstat auf GitHub
• stress-ng auf GitHub