CPU-Steal-Time auf virtualisierten Linux-Hosts mit mpstat und vmstat diagnostizieren

Ziel

Echte CPU-Erschöpfung von der Zeit unterscheiden, in der die vCPU einer virtuellen Maschine darauf wartete, vom Host eingeplant zu werden – bevor nach einer Korrektur auf Anwendungsebene gesucht wird, die es gar nicht geben kann.

Voraussetzungen

Ein Linux-Gast unter einem Hypervisor (KVM, Xen, VMware oder eine Cloud-VM), der dem Gast eine Steal-Time-Uhr bereitstellt (KVM und Xen tun das; nicht jeder Hypervisor und nicht jeder Gast-Kernel meldet sie). Ausserdem das Paket sysstat für mpstat und procps für vmstat; beide sind normalerweise vorinstalliert oder lassen sich nicht-interaktiv installieren (DEBIAN_FRONTEND=noninteractive apt-get install -y sysstat / dnf install -y sysstat).

Schritte

1. Über ein kurzes Zeitfenster eine Aufschlüsselung pro CPU erstellen: mpstat -P ALL 1 5. Das Handbuch von sysstat definiert %steal als den Anteil der Zeit, in dem die virtuelle CPU unfreiwillig wartete, weil der Hypervisor gerade einen anderen virtuellen Prozessor bediente – also Zeit, in der der Kernel des Gasts laufen wollte, aber nicht konnte, und nicht Zeit, in der er etwas getan hat.
2. Mit einem zweiten Werkzeug gegenprüfen: vmstat 1 5. Die Spalte st ist dokumentiert als der einer virtuellen Maschine entzogene (gestohlene) Zeitanteil; sie sollte in etwa dem %steal der Zeile all von mpstat folgen. Die erste Zeile von vmstat ignorieren: Sie ist ein Durchschnitt seit dem Systemstart und zeigt nicht das aktuelle Intervall.
3. Das Muster lesen, nicht nur die Zahl: Steal, der sich im Intervall gleichmässig auf alle CPUs verteilt, deutet auf hostweite Scheduling-Contention hin; Steal, der nur auftritt, solange die eigene Last CPU-gebunden ist, deutet darauf hin, dass der Host für diese Art von Last überbucht ist. Steal fällt nur an, solange eine vCPU Arbeit zu erledigen hat; ein weitgehend untätiger Gast zeigt daher selbst auf einem ausgelasteten Host wenig Steal.
4. Das Ergebnis als Frage der Platzierung oder Kapazität behandeln, nicht als Codefehler: Im Gast lässt sich nicht erkennen, was benachbarte virtuelle Maschinen zu diesem Zeitpunkt taten. Anhaltender, substanzieller Steal (deutlich über kurzem Jitter im einstelligen Bereich) sollte bei der Stelle angesprochen werden, die den Hypervisor kontrolliert. Bei Cloud-Instanztypen mit Burst-Kontingent können auch aufgebrauchte CPU-Credits als Steal erscheinen.
5. Auf Bare Metal sind %steal und st strukturbedingt null, da kein Hypervisor existiert, der CPU-Zeit vorenthalten könnte; ein Wert ungleich null deutet darauf hin, dass das System entgegen der Annahme tatsächlich ein Gast ist.
6. Wer auch den Hypervisor kontrolliert, korreliert die Werte mit dessen eigenen Metriken pro VM, etwa CPU-Ready oder Scheduler-Wartezeit; sie bestätigen von der anderen Seite, was der Gast nur erschliessen kann.

Erwartetes Ergebnis

Eine klare Trennung zwischen «Die Anwendung hat die gesamte ihr zugeteilte CPU genutzt» (wenig Steal, hohe Werte bei us/sy) und «Der Anwendung wurde angeforderte CPU verweigert» (substanzieller, anhaltender Steal). Dadurch wechselt der nächste Schritt vom Profiling des Codes zu einem Gespräch über Kapazität.

Grenzen und Prüfbasis

Beide Befehle sind rein lesend; es gibt nichts zu sichern oder rückgängig zu machen. Keines der Werkzeuge kann den für die Contention verantwortlichen Mandanten benennen. Manche Hypervisor-Konfigurationen (CPU-Pinning, dedizierte Kerne) erzeugen selbst unter Last nie Steal, und manche Hypervisoren melden Steal gar nicht an den Gast; Steal von null beweist daher für sich genommen nicht, dass keine hostseitige Contention besteht. Die angeführten Definitionen stammen von den Werkzeugen selbst und sind kein allgemeingültiger Schwellenwert für die Schwere.