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.

Herkunft des Steal-Werts

Ihr Kernel kann Steal nicht eigenständig messen, da er den Host nicht sehen kann. Der Hypervisor übermittelt diesen Wert. Unter KVM schreibt der Host einen Zähler pro vCPU in eine Seite, die mit dem Gast geteilt wird. Der Gast summiert diesen Wert, sofern der Kernel mit CONFIG_PARAVIRT_TIME_ACCOUNTING kompiliert wurde, was bei jedem Distributions-Kernel der Fall ist. Xen meldet denselben Wert über seinen Runstate-Bereich. Die Gesamtsumme erreicht den Userspace an genau einer Stelle:

head -1 /proc/stat

Diese cpu-Zeile enthält zehn Zähler in USER_HZ-Ticks seit dem Bootvorgang in folgender Reihenfolge: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice. Steal ist der achte Wert nach dem Label. Jedes der unten genannten Tools, vmstat, top, mpstat sowie jeder Prometheus-Exporter, liest dieses Feld aus und berechnet aus zwei Stichproben einen Prozentwert.

Eine Konsequenz ist dabei besonders wichtig. Wenn der Hypervisor den Zähler nicht exportiert, bleibt das Feld dauerhaft auf null, und jedes darauf basierende Tool meldet einen unauffälligen 0.0-Wert, während der Host überlastet ist. KVM und Xen exportieren diesen Wert. Auf anderen Plattformen, darunter VMware und Hyper-V, hängt die Sichtbarkeit von Steal davon ab, was der Host bereitstellt und was der Gast-Kernel unterstützt. Ein Wert von null beweist dort also für sich genommen nichts. Prüfen Sie die Plattform, bevor Sie einem Nullwert vertrauen:

systemd-detect-virt

Dieser Befehl gibt den Plattformnamen aus, wie etwa kvm, xen, vmware oder microsoft, sowie none auf Bare-Metal-Systemen. Innerhalb eines Containers wird stattdessen die Laufzeitumgebung gemeldet, wie etwa lxc, docker oder podman; dies gibt Auskunft über den Container, nicht über die zugrunde liegende Maschine. Auf kvm ist eine Null ein echter Beleg dafür, dass der Host Sie gut behandelt. Auf einer Plattform, die dieses Feld niemals befüllt, ist eine Null kein Beweis; in diesem Fall muss die Auslastung durch das Messen tatsächlicher Arbeitsvorgänge beurteilt werden.

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

vmstat ist Teil des Pakets procps. Es ist auf fast jedem Ubuntu- und Debian-VPS-Image vorhanden, fehlt jedoch in einigen minimalen Container-Images. Installieren Sie es daher, bevor Sie es verwenden.

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 gibt daraufhin fünf Berichte aus: Der erste ist der Durchschnitt seit dem Systemstart, die folgenden vier sind einsekündige Stichproben.

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 die Spalte st im Block cpu auf der rechten Seite. Aktuelle procps-ng-Builds geben danach eine Spalte gu für die KVM-Gastzeit aus, weshalb st nicht mehr an letzter, sondern an vorletzter Stelle steht. Lesen Sie die Spalte anhand ihres Spaltennamens ab, da sich die Position zwischen den Releases geändert hat.

Zwei Vorgehensweisen sorgen für eine korrekte Interpretation. Die erste Datenzeile ist der Durchschnitt seit dem Systemstart, ignorieren Sie diese also und lesen Sie die folgenden Zeilen. Eine einzelne Stichprobe ist keine Messung, da Steal-Time in Schüben auftritt: Führen Sie vmstat 1 61 aus, was nach der Durchschnittszeile sechzig einsekündige Stichproben liefert. Beobachten Sie den Wert eine volle Minute lang, bevor Sie eine Schlussfolgerung ziehen.

top meldet denselben Wert in der Zusammenfassungszeile %Cpu(s) im Feld st:

%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 Kern 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. Diese zeigt, ob alle vCPUs betroffen sind oder nur eine einzelne. Für die Historie, die ein Support-Ticket erfordert, sollten Sie die Stichproben speichern, anstatt sie nur vom Bildschirm abzulesen:

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

Führen Sie dies über cron während der Stunden aus, in denen Sie Probleme vermuten. Die Datei ist dann der entscheidende Unterschied zwischen der Aussage gegenüber dem Provider „es fühlte sich letzte Nacht langsam an“ und dem Nachweis der exakten zehn Minuten.

Was bedeuten die Steal-Werte?

• Ein konstanter Wert von 0.0. Der Zustand ist gesund, oder die Plattform meldet den Steal-Wert gar nicht. Überprüfen Sie dies mit systemd-detect-virt, bevor Sie von einem fehlerfreien Zustand ausgehen.
• Kurze Spitzen von wenigen Prozent über einige Sekunden. Dies ist auf jedem Shared-Node normal. Ein Build-Prozess eines Nachbarn startet oder der Host führt seine Backups aus.
• Anhaltende 1 bis 5 Prozent auf einem Shared-Tarif. Dies ist zu erwarten. Der Preis spiegelt die Nutzung geteilter CPU-Ressourcen wider.
• Anhaltende 5 bis 10 Prozent. Eine messbare Verlangsamung. Beginnen Sie mit der Protokollierung und vergleichen Sie die Werte über mehrere Tage hinweg zur gleichen Uhrzeit.
• Über 10 Prozent über mehrere Stunden hinweg. Entweder ist der Node für Ihre Arbeitslast überbucht, oder das CPU-Limit Ihres Tarifs wird erzwungen – einige Anbieter melden dieses Limit als Steal. Ab diesem Wert ist ein Support-Ticket oder ein Umzug gerechtfertigt.

Betrachten Sie diese Bereiche als Orientierungshilfe und nicht als Spezifikation, da kein Anbieter eine Steal-Garantie für Shared-Tarife veröffentlicht. Bewerten Sie die Werte basierend auf Ihren Anwendungen. Ein nächtlicher Batch-Job kann 15 Prozent Steal verkraften, ohne dass es jemand bemerkt. Ein latenzempfindlicher Dienst zeigt dies in der p99-Latenz, lange bevor der Durchschnittswert alarmierend wirkt. Deshalb gehören latenzempfindliche Arbeitslasten wie Trading-Bots auf dedizierte Kerne.

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.

Umgang mit anhaltendem Steal

Keine Einstellung innerhalb des Gastsystems behebt Steal, da der Scheduler, der diese Entscheidung trifft, außerhalb des Gastsystems läuft. Auch ein Kernel-Upgrade ändert daran nichts: Das in Linux-Kernel 7.2 hinzugefügte Cache-bewusste Scheduling ordnet Ihre Aufgaben lediglich auf den Ihnen tatsächlich zugewiesenen Kernen neu an, kann aber die Zyklen, die ein Nachbar bereits beansprucht hat, nicht zurückgewinnen. Es gibt vier reale Handlungsoptionen.

Sammeln Sie zuerst Beweise. Notieren Sie Zeitstempel in UTC, die Dauer jedes Vorfalls, die Wiederholungsrate und ob mpstat eine einzelne vCPU oder alle betroffenen vCPUs anzeigt. Eine Woche protokollierter Stichproben ist wertvoller als ein Screenshot.

Eröffnen Sie ein Ticket mit diesen Daten. Stellen Sie zwei direkte Fragen: Ist dieser Knoten in diesen Zeitfenstern überbucht und kann meine Instanz verschoben werden? Fügen Sie die Ausgabe von vmstat und die exakten Uhrzeiten bei. Anbieter reagieren auf reproduzierbare Zeitfenster; ein Ticket, das lediglich besagt, der Server sei langsam, erhält als Antwort die Aufforderung, diese Daten nachzureichen. 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. Das Verschieben eines Gastsystems auf einen weniger ausgelasteten Knoten ist Routinearbeit für einen Anbieter und erfordert in der Regel nur einen kurzen Neustart. Dies ist die Lösung, die nichts kostet und den Regelfall behebt, bei dem ein Knoten zufällig mehrere rechenintensive Nachbarn gleichzeitig beherbergt.

Kaufen Sie sich von der Konkurrenz frei. Ein Plan mit dedizierten vCPUs reserviert CPU-Kapazität für Ihre Instanz – je nach Anbieter einen vollständigen Kern oder einen vollständigen Hardware-Thread –, sodass Nachbarn Ihre Zyklen nicht mehr beanspruchen können und der Zähler bei oder sehr nahe bei null bleibt. Die interne Verwaltung des Hypervisors kann dennoch einen geringen Restwert hinterlassen. Dies kostet monatlich mehr und ist die ehrliche Antwort für eine Arbeitslast, die keine Varianz tolerieren kann. Wenn das immer noch nicht ausreicht oder Sie auch die Speicherbandbreite exklusiv nutzen möchten, ist der nächste Schritt ein dedizierter Server anstelle eines VPS.

Während Sie auf eine dieser Maßnahmen warten, reduzieren Sie die Auswirkungen des Steal. Betreiben Sie weniger Worker-Threads, als Sie vCPUs haben, da Threads, die keinen Kern erhalten, nur zusätzliche Kontextwechsel verursachen. Verschieben Sie Batch-Aufgaben in die Zeiten, in denen der Knoten weniger ausgelastet ist, was Sie nun Ihren eigenen Protokollen entnehmen können. Messen Sie anschließend erneut mit demselben Befehl über dieselben Zeiträume, damit Sie belegen können, ob die Änderung funktioniert hat, anstatt zu spekulieren.

FAQ

Was ist ein normaler CPU-Steal-Wert auf einem VPS?

Auf einem Shared-Tarif sind kurze Spitzen und ein dauerhafter Wert unter etwa 5 Prozent normal, da sich bei geteilten CPUs der Host die physischen Kerne zwischen den Gästen aufteilt. Dauerhafte zweistellige Werte über mehrere Stunden sind unüblich und sollten per Ticket gemeldet werden. Bei einem Tarif mit dedizierter vCPU liegt der erwartete Wert bei oder sehr nahe bei 0.0, da die Verwaltung durch den Hypervisor immer einen kleinen Anteil beanspruchen kann; ein dauerhafter Steal-Wert darüber ist ein Fehler, der gemeldet werden muss. Bewerten Sie den Wert anhand Ihrer Arbeitslast: Ein Batch-Job über Nacht verträgt Steal, eine latenzempfindliche API hingegen nicht.

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

Nicht von allein. Mehr vCPUs auf demselben Shared-Node bedeuten mehr virtuelle CPUs, die um dieselben physischen Kerne konkurrieren; der prozentuale Wert kann exakt gleich bleiben. Was den Steal-Wert nahezu vollständig eliminiert, ist eine dedizierte CPU-Zuweisung oder der Umzug auf einen weniger ausgelasteten Node. Ein größerer Anteil an einer ausgelasteten Maschine ist immer noch ein Anteil an einer ausgelasteten Maschine.

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

Dafür gibt es zwei häufige Gründe. Der Hypervisor exportiert den Zähler möglicherweise gar nicht; dies tritt auf manchen Plattformen abhängig vom Host und dem Gast-Kernel auf, sodass das Feld unabhängig vom Host-Verhalten bei Null bleibt. Führen Sie systemd-detect-virt aus, um zu sehen, auf welcher Plattform Sie sich befinden. Andernfalls liegt der Flaschenhals woanders: Prüfen Sie wa auf Speicher-Wartezeiten, vergleichen Sie r mit nproc hinsichtlich Ihrer eigenen Überlastung und lesen Sie /sys/fs/cgroup/cpu.stat innerhalb von Containern auf Quota-Drosselung.

Kann ich die Steal-Zeit von meinem Server aus reduzieren?

Sie können das Scheduling des Hosts nicht vom Gast aus ändern. Sie können lediglich die Auswirkungen minimieren. Lassen Sie weniger Worker-Threads laufen, als Sie vCPUs haben, damit weniger Arbeit in der Run-Queue auf einen Kern wartet, der nicht verfügbar ist. Verschieben Sie Batch-Jobs auf Zeiten, in denen der Node weniger ausgelastet ist. Cachen Sie Ergebnisse, damit weniger Anfragen überhaupt CPU-Leistung benötigen. Die Änderungen, die den Steal-Wert tatsächlich beseitigen – eine Migration auf einen anderen Node oder dedizierte Kerne – liegen im Verantwortungsbereich des Anbieters.