CPU-Steal-Time und noisy Neighbours im VPS erkennen

Was die CPU-Steal-Time tatsächlich misst

Die CPU-Steal-Time ist der Anteil der Zeit, in der Ihre virtuelle CPU ausführungsbereit war und auf nichts warten musste, während der Hypervisor den physischen Kern einem anderen Gast zugewiesen hatte. Die Arbeit war eingereiht. Der Kern war anderweitig belegt. Linux zählt diese Zyklen separat und meldet sie als st. Dadurch können Sie unterscheiden, ob „mein Server ausgelastet ist“ oder „mein Server auf seine Ausführungszeit wartet“.

Genau deshalb gibt es diesen Zähler. Die Zeit, die Ihre eigenen Prozesse auf der CPU verbringen, wird als us (User) oder sy (System) gemeldet. Die Zeit, während der eine Aufgabe auf Speicher-I/O blockiert ist, wird als wa (I/O Wait) gemeldet. Eine vCPU (virtuelle CPU), die ausführungsbereit in der Run Queue wartet, keine ausstehende I/O hat und trotzdem nicht ausgeführt wird, wird als st gemeldet. Nichts innerhalb Ihres Servers kann diesen Zustand aufheben, weil die Scheduling-Entscheidung eine Ebene unterhalb Ihres Servers auf dem Host getroffen wird.

Das ergibt sich direkt daraus, wie ein VPS eine physische Maschine unter mehreren Gästen aufteilt. Die übliche Ursache ist ein Nachbar: Ein anderer Gast auf demselben Node ist stark ausgelastet, sodass der Host die Kerne zwischen Ihnen aufteilt. Es gibt noch eine zweite Ursache, die häufig übersehen wird. Viele Provider begrenzen eine gemeinsam genutzte vCPU auf einen Bruchteil eines physischen Kerns. Bei mehreren Hypervisoren wird diese erzwungene Begrenzung innerhalb des Gasts als Steal erfasst. Ein hoher st-Wert zeigt daher, dass der Kern Ihnen nicht zugewiesen wurde. Er zeigt jedoch nicht immer, wer ihn erhalten hat.

Woher der Steal-Wert stammt

Der Kernel kann Steal nicht selbst messen, weil er den Host nicht sehen kann. Der Hypervisor stellt diesen Wert bereit. Unter KVM schreibt der Host einen Zähler pro vCPU in eine mit dem Gast gemeinsam genutzte Speicherseite. Der Gast addiert die Werte, wenn der Kernel mit CONFIG_PARAVIRT_TIME_ACCOUNTING gebaut wurde. Das ist bei jedem Distributionskernel der Fall. Xen meldet denselben Wert über seinen Runstate-Bereich. Die Summe erreicht den Userspace genau an einer Stelle:

head -1 /proc/stat

Diese cpu-Zeile enthält zehn Zähler in USER_HZ-Ticks seit dem Systemstart, und zwar in dieser Reihenfolge: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice. Steal ist der achte Wert nach dem Bezeichner. Jedes der folgenden Tools, vmstat, top, mpstat und jeder Prometheus-Exporter liest dasselbe Feld und berechnet aus zwei Messwerten einen Prozentsatz.

Eine Konsequenz ist besonders wichtig. Wenn der Hypervisor den Zähler nie exportiert, bleibt das Feld dauerhaft auf 0. Jedes darauf basierende Tool meldet dann einen unauffälligen 0.0, obwohl der Host überlastet ist. KVM und Xen exportieren diesen Wert. Gäste unter VMware und Hyper-V melden häufig dauerhaft 0. Prüfen Sie die Plattform, bevor Sie einem Wert von 0 vertrauen:

systemd-detect-virt

Der Befehl gibt den Plattformnamen aus, beispielsweise kvm, xen, vmware oder microsoft, und none auf Bare Metal. In einem Container wird stattdessen die Laufzeitumgebung gemeldet, beispielsweise lxc, docker oder podman. Das beschreibt den Container, nicht das darunterliegende System. Unter kvm ist ein Wert von 0 ein tatsächlicher Hinweis darauf, dass der Host Sie bevorzugt behandelt. Auf einer Plattform, die das Feld nie befüllt, liefert ein Wert von 0 dagegen keinerlei Aussage. Die Konkurrenz um CPU-Zeit muss dort anhand der Laufzeit echter Arbeitslast beurteilt werden.

Wie prüfe ich CPU-Steal-Time auf einem VPS?

vmstat stammt aus dem Paket procps. Es ist in fast jedem Ubuntu- und Debian-VPS-Image enthalten, fehlt aber in einigen minimalen Container-Images. Installieren Sie es daher, bevor Sie darauf angewiesen sind.

sudo apt-get update
sudo apt-get install -y procps
vmstat --version
vmstat 1 5

vmstat --version gibt eine Zeile wie vmstat from procps-ng 4.0.4 aus. Wenn diese Ausgabe erscheint, ist das Tool installiert, und Sie lesen echte Kernel-Zähler aus. vmstat 1 5 erfasst anschließend fünfmal jeweils ein Sample pro Sekunde.

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 1  0      0 3216484  98304 1284360    0    0     4    18   62  110  3  1 96  0  0  0
 2  0      0 3216232  98304 1284360    0    0     0     0  248  431  6  2 84  0  8  0

Suchen Sie im Block cpu rechts nach der Spalte st. Aktuelle procps-ng-Builds geben danach für die KVM-Gastzeit eine Spalte gu aus. Daher steht st an vorletzter statt an letzter Stelle. Lesen Sie die Spalte anhand ihres Headernamens aus, da sich diese Position zwischen Releases geändert hat.

Zwei Gewohnheiten sorgen für eine korrekte Auswertung. Die erste Datenzeile ist der Durchschnitt seit dem Boot, ignorieren Sie sie daher und lesen Sie die folgenden Zeilen. Ein einzelnes Sample ist außerdem keine Messung, da Steal-Time in Schüben auftritt. Führen Sie vmstat 1 60 aus und beobachten Sie eine volle Minute, bevor Sie eine Schlussfolgerung ziehen.

top gibt denselben Wert in seiner Zusammenfassungszeile %Cpu(s) aus, und zwar im mit st gekennzeichneten Feld:

%Cpu(s):  6.2 us,  2.1 sy,  0.0 ni, 83.9 id,  0.0 wa,  0.0 hi,  0.3 si,  7.5 st

Für Details pro CPU fügen Sie sysstat hinzu:

sudo apt-get install -y sysstat
mpstat -P ALL 1 5

mpstat gibt eine Zeile pro CPU mit einer Spalte %steal aus. Daraus geht hervor, ob jede vCPU betroffen ist oder nur eine. Für den Verlauf, den ein Support-Ticket benötigt, speichern Sie die Samples, statt sie vom Bildschirm abzulesen:

date -u | tee -a ~/steal.log
mpstat -P ALL 1 5 | tee -a ~/steal.log

Führen Sie den Befehl über cron während der vermuteten Zeiträume aus. Dann zeigt die Datei nicht nur, dass der Server „gestern Abend langsam wirkte“, sondern dokumentiert die genauen zehn Minuten.

Was bedeuten die Steal-Werte?

• Ein konstanter Wert von 0.0. Das System ist gesund, oder die Plattform meldet Steal überhaupt nicht. Prüfen Sie dies mit systemd-detect-virt, bevor Sie Entwarnung geben.
• Spitzen von wenigen Prozent über mehrere Sekunden. Das ist auf jedem gemeinsam genutzten Node normal. Der Build eines Nachbarn startet, oder der Host führt seine Backups aus.
• Dauerhaft 1 bis 5 Prozent bei einem Shared-Tarif. Das ist zu erwarten. Die gemeinsam genutzte CPU entspricht dem Preis.
• Dauerhaft 5 bis 10 Prozent. Die Verlangsamung ist messbar. Beginnen Sie mit der Dokumentation und vergleichen Sie dieselben Uhrzeiten über mehrere Tage.
• Über 10 Prozent über mehrere Stunden hinweg. Der Node ist für Ihre Arbeitslast überbucht. Ab diesem Wert sind ein Support-Ticket oder ein Wechsel gerechtfertigt.

Betrachten Sie diese Bereiche als Orientierung und nicht als Spezifikation, da kein Anbieter eine Steal-Garantie für einen Shared-Tarif veröffentlicht. Bewerten Sie sie im Zusammenhang mit Ihrer Arbeitslast. Ein nächtlicher Batch-Job kann 15 Prozent Steal verkraften, ohne dass es jemand bemerkt. Ein latenzsensibler Dienst zeigt die Auswirkungen bereits im p99, lange bevor der Durchschnittswert alarmierend aussieht. Deshalb gehören latenzsensible Arbeitslasten wie Trading-Bots auf dedizierte Cores.

Wie viel kostet Sie Steal Time?

Die Berechnung ist kurz. Wenn ein Anteil s Ihrer CPU-Zeit entzogen wird, benötigt ein Prozess mit einem festen CPU-Bedarf auf der Uhr 1 / (1 - s)-mal so lange. Für einen Prozess, der 60 Sekunden CPU-Zeit benötigt:

[
  {
    "steal_percent": 0,
    "wall_clock_seconds": "60.0"
  },
  {
    "steal_percent": 3,
    "wall_clock_seconds": "61.9"
  },
  {
    "steal_percent": 8,
    "wall_clock_seconds": "65.2"
  },
  {
    "steal_percent": 15,
    "wall_clock_seconds": "70.6"
  },
  {
    "steal_percent": 25,
    "wall_clock_seconds": "80.0"
  },
  {
    "steal_percent": 40,
    "wall_clock_seconds": "100.0"
  }
]

Bei 3 Prozent, einem gewöhnlichen Wert bei gemeinsam genutzten Tarifen, benötigt der Prozess 61.9 Sekunden statt 60.0. Dafür eröffnet niemand ein Ticket. Bei 8 Prozent sind es 65.2 Sekunden. Bei 40 Prozent benötigt derselbe Prozess 100.0 Sekunden, und eine Warteschlange, die zuvor abgebaut wurde, wächst stattdessen weiter.

Das sind berechnete Werte, keine Messungen. Das Modell setzt einen einzelnen ausführbaren Thread voraus und nimmt an, dass Steal Time gleichmäßig über das Intervall verteilt ist. In realen Diensten wirkt sich das oft stärker aus als in der Kurve, weil ein entzogenes Zeitfenster mitten in einer Anfrage liegt. Die Verzögerung betrifft dann auch alle Prozesse, die auf diese Anfrage warten. Um Ihren eigenen Wert statt einer Formel zu ermitteln, testen Sie die Leistung des VPS während einer ruhigen Stunde und erneut während einer ausgelasteten Stunde. Protokollieren Sie st für beide Zeitfenster.

Ist es Steal oder etwas anderes?

Steal lässt sich leicht mit anderen Symptomen verwechseln. Lesen Sie die Zähler gemeinsam in derselben vmstat-Zeile.

• st ist hoch, während r und us niedrig bleiben: Der Host stellt Ihnen den Core nicht zur Verfügung. Das ist Steal.
• r liegt deutlich über der Anzahl Ihrer vCPUs, us ist hoch und st liegt nahe null: Sie führen mehr Arbeit aus, als Ihre eigenen CPUs bewältigen können. Vergleichen Sie r mit der Ausgabe von nproc. Das ist Ihre eigene Überbelegung, nicht die eines Nachbarn.
• wa ist hoch und st liegt nahe null: Tasks warten auf den Storage. Das ist ein anderes Problem mit einer anderen Lösung.
• Der Load Average ist hoch, während st und us beide niedrig sind: Die Load-Angabe zählt auch nicht unterbrechbare Tasks. Das deutet daher meist auf ein blockiertes Gerät oder einen hängenden Netzwerk-Mount hin und nicht auf CPU.

Burstable-Tarife verdienen eine eigene Erläuterung. Sie stellen ein Credit-Guthaben bereit, das sich bei geringer Auslastung aufbaut und bei hoher Auslastung abbaut. Wenn es aufgebraucht ist, begrenzt der Provider Sie auf eine Basisrate. Auf einigen Plattformen wird diese Drosselung als Steal gemeldet. Auf anderen ist sie innerhalb der Instanz nicht sichtbar, und Sie erhalten einfach weniger CPU-Zyklen pro Sekunde. Lesen Sie die Tarifbeschreibung, bevor Sie einen Nachbarn verantwortlich machen.

Warum ein Container keine Steal Time meldet

Steal ist eine Eigenschaft der virtuellen Maschine, nicht eines darin laufenden Containers. Ein Docker-Container auf Ihrem eigenen VPS teilt sich die /proc des Hosts. Daher entspricht ein darin gelesener st-Wert der Steal Time des VPS. Das ist der gewünschte Wert. Eine containerbasierte Virtualisierung, die als VPS angeboten wird, verhält sich anders. Wenn lxcfs verwendet wird, wird /proc/stat innerhalb des Containers aus der cgroup-Abrechnung synthetisiert. Die Steal Time ist konstruktionsbedingt null. Ein Monitoring-Stack, der nur innerhalb des Containers Daten abruft, kann daher einen konstanten, unauffälligen Nullwert anzeigen, während die physische Maschine darunter unter Ressourcenmangel leidet.

Innerhalb eines Containers ist die CPU-Quota-Drosselung der Zähler mit derselben Aussage. Unter cgroup v2:

cat /sys/fs/cgroup/cpu.stat

nr_throttled zählt die Zeiträume, in denen die Gruppe ihr CPU-Limit erreicht hat. throttled_usec summiert die Zeit, in der sie angehalten wurde. Ein steigender Wert bei nr_throttled bedeutet, dass Ihr Prozess ausführbar war, aber nicht ausgeführt wurde. Das entspricht der Erfahrung bei Steal Time, wird hier aber durch ein von Ihnen selbst gesetztes Limit verursacht. Prüfen Sie Ihre eigenen Limits, bevor Sie den Host verantwortlich machen. Das gilt besonders, wenn Sie Ihre Dienste in Docker auf einem VPS ausführen und in der Compose-Datei CPU-Limits festgelegt sind. Eine geschachtelte Virtualisierung fügt eine weitere Stelle hinzu, an der CPU-Zeit verloren gehen kann. Eine VM innerhalb Ihres VPS trägt sowohl dessen Steal Time als auch ihre eigene Verzögerung bei der CPU-Zuteilung. Berücksichtigen Sie das, wenn Sie geschachtelte Virtualisierung auf einem VPS ausführen.

Was Sie gegen anhaltenden Steal tun können

Keine Einstellung innerhalb des Gasts behebt Steal, weil der Scheduler, der diese Entscheidung trifft, außerhalb des Gasts läuft. Auch ein Kernel-Upgrade ändert daran nichts: Das in Linux kernel 7.2 hinzugefügte cachebewusste Scheduling verteilt Ihre Tasks auf die Kerne, die Ihnen tatsächlich zugewiesen wurden, und kann die Zyklen nicht zurückholen, die ein Nachbar bereits verbraucht hat. Vier Maßnahmen sind sinnvoll.

Sammeln Sie zuerst Belege. Erfassen Sie die Zeitstempel in UTC, die Dauer jeder Phase, die Wiederholungsrate und ob mpstat eine betroffene vCPU oder alle vCPUs anzeigt. Eine Woche protokollierter Messwerte ist aussagekräftiger als ein Screenshot.

Eröffnen Sie mit diesen Daten ein Ticket. Stellen Sie zwei direkte Fragen: Ist dieser Node in diesen Zeitfenstern überbelegt, und kann meine Instanz verschoben werden? Fügen Sie die Ausgabe von vmstat und die genauen Zeitpunkte ein. Anbieter können mit einem reproduzierbaren Zeitfenster arbeiten. Auf ein Ticket, das nur meldet, dass der Server langsam ist, bitten sie meist um genau diese Angaben. Wie viel dieser Arbeit Sie abgeben können, ist einer der praktischen Unterschiede zwischen einem verwalteten und einem nicht verwalteten VPS.

Bitten Sie um eine Migration. Einen Gast auf einen weniger ausgelasteten Node zu verschieben, ist für einen Anbieter Routinearbeit und erfordert normalerweise nur einen kurzen Reboot. Diese Lösung kostet nichts. Sie behebt den häufigen Fall, dass sich zufällig mehrere stark ausgelastete Nachbarn auf einem Node befinden.

Buchen Sie ein Angebot ohne diese Konkurrenz. Ein Angebot mit dedizierten vCPUs reserviert physische Kerne für Ihre Instanz. Dadurch bleibt der Zähler bei null. Es kostet monatlich mehr. Für eine Workload, die diese Schwankungen nicht verkraftet, ist das die ehrliche Antwort. Wenn das noch nicht ausreicht oder Sie auch die Speicherbandbreite exklusiv nutzen möchten, ist der nächste Schritt ein dedizierter Server statt eines VPS.

Reduzieren Sie in der Zwischenzeit die Auswirkungen von Steal. Führen Sie weniger Worker-Threads aus, als Sie vCPUs haben. Threads, die keinen Kern erhalten, verursachen nur zusätzliche Kontextwechsel. Verschieben Sie Batch-Arbeiten in die Stunden, in denen der Node wenig ausgelastet ist. Das zeigt Ihnen jetzt Ihr eigenes Log. Messen Sie anschließend mit demselben Befehl über dieselben Stunden erneut. So können Sie feststellen, ob die Änderung wirksam war, statt zu raten.

FAQ

Was ist eine normale CPU-Steal-Time auf einem VPS?

Bei einem Shared-Tarif sind kurze Spitzen und ein dauerhaftes Niveau unter etwa 5 Prozent normal, weil sich mehrere Gäste die physischen CPU-Kerne des Hosts teilen. Ein über Stunden anhaltender zweistelliger Wert ist nicht normal und sollte dem Support gemeldet werden. Bei einem Tarif mit dedizierter vCPU lautet der erwartete Wert 0.0. Jeder andere Wert sollte als Fehler gemeldet werden. Bewerten Sie den Wert im Zusammenhang mit Ihrer eigenen Arbeitslast: Ein nächtlicher Batch-Job kann Steal-Time verkraften, eine latenzempfindliche API dagegen nicht.

Behebt ein größerer Tarif eine hohe Steal-Time?

Nicht automatisch. Mehr vCPUs auf demselben gemeinsam genutzten Node bedeuten mehr virtuelle CPUs, die um dieselben ausgelasteten physischen Kerne konkurrieren. Der Prozentsatz kann daher unverändert bleiben. Steal-Time lässt sich durch eine dedizierte CPU-Zuweisung oder den Umzug auf einen weniger ausgelasteten Node beseitigen. Ein größerer Anteil an einer ausgelasteten Maschine bleibt ein Anteil an einer ausgelasteten Maschine.

Warum zeigt mein VPS 0 Steal-Time an, obwohl er offensichtlich langsam ist?

Dafür gibt es zwei häufige Gründe. Der Hypervisor exportiert den Zähler möglicherweise überhaupt nicht. Das ist auf VMware- und Hyper-V-Plattformen üblich. Das Feld bleibt dann unabhängig von der Auslastung des Hosts auf null. Führen Sie systemd-detect-virt aus, um die verwendete Plattform zu prüfen. Andernfalls liegt der Engpass an anderer Stelle: Prüfen Sie wa auf Wartezeiten beim Storage, vergleichen Sie r mit nproc auf eine Überlastung Ihrer eigenen Umgebung und prüfen Sie innerhalb von Containern /sys/fs/cgroup/cpu.stat auf Drosselung durch Quoten.

Kann ich die Steal-Time innerhalb meines Servers reduzieren?

Sie können die Scheduling-Entscheidungen des Hosts nicht innerhalb des Gasts ändern. Sie können nur die Auswirkungen reduzieren. Verwenden Sie weniger Worker-Threads als vCPUs, damit weniger Arbeit in der Run-Queue auf einen nicht verfügbaren CPU-Kern wartet. Verschieben Sie Batch-Jobs auf Zeiten, in denen der Node weniger ausgelastet ist. Cachen Sie Ergebnisse, damit Anfragen möglichst wenig CPU benötigen. Die Maßnahmen, die Steal-Time tatsächlich beseitigen, liegen beim Provider: der Umzug auf einen anderen Node oder die Zuweisung dedizierter Kerne.