CPU Ready in VMware vSphere: wie Sie den Wert lesen, welche Schwellenwerte gelten und was die Zahl der vCPU je Kern aussagt

Was CPU Ready in VMware vSphere bedeutet

CPU Ready ist die Zeit, in der eine virtuelle CPU bereit zur Ausführung war, aber nicht auf einer physischen CPU eingeplant werden konnte. Der Zähler Ready in vCenter summiert diese Zeit in Millisekunden über jedes Messintervall, und esxtop zeigt dieselbe Zeit auf dem Host als %RDY, als Prozentsatz des Messintervalls. Mit der Formel aus Broadcoms KB 306576 in Prozent umgerechnet und durch die Zahl der vCPUs geteilt, lässt sich der Wert mit den Schwellenwerten aus Broadcoms KB 438023 vergleichen, in der es heißt: „In der Branche anerkannte Schwellenwerte sind unter etwa 5 % je vCPU für unbedenkliches Verhalten, 5 % bis 10 % je vCPU zur Untersuchung und über 10 % je vCPU für eine spürbare Leistungsbeeinträchtigung.“

Broadcoms API-Referenz definiert den vCenter-Zähler als „Zeit, in der die virtuelle Maschine bereit war, aber im letzten Messintervall nicht zur Ausführung auf der physischen CPU eingeplant werden konnte“. In esxtop teilt sich die Zeit jeder vCPU in einem Messintervall in Run, Ready, Co-Stop und Wait auf, was die Dokumentation als 100% = %RUN + %RDY + %CSTP + %WAIT schreibt. Zeit im Zustand Ready ist Zeit, in der die vCPU nicht läuft; die CPU-Nutzung zeigt sie daher nicht, und die Dokumentation zu vSphere 8.0 ergänzt: „Die CPU-Ready-Zeit hängt von der Zahl der virtuellen Maschinen auf dem Host und deren CPU-Last ab.“

CPU Ready von Millisekunden in Prozent umrechnen

KB 306576 teilt den Summenwert durch das Diagrammintervall in Millisekunden und multipliziert mit 100, was ready % = ms / (seconds × 1000) × 100 ergibt. Als Beispiel nennt die KB einen Wert von 1.000 ms im Diagramm Realtime, der über das 20-Sekunden-Intervall 5 % ergibt.

Broadcom KB 306576: Standard-Aktualisierungsintervalle und Divisor je Diagramm; letzte Spalte: unsere Rechnung.

KB 306576 merkt außerdem an, dass das Ergebnis eine Summe über die vCPUs ist und dass sich Ready je vCPU grob schätzen lässt, indem man durch ihre Zahl teilt. Eine VM mit 4 vCPU und 3.200 ms in einem 20-Sekunden-Intervall liegt für die VM bei 16 %. Je vCPU sind das etwa 4 %, unter den 5 % aus KB 438023. In einem Messpunkt des Diagramms Past day ergeben dieselben 3.200 ms etwa 1 % für die ganze VM.

Die Ready-Linie der VM selbst im erweiterten Diagramm ist diese Summe für die VM, ebenso die Zeile der VM in esxtop, da die KB das eine in das andere umrechnet. Die Linien je vCPU, die vCenter ab Statistikebene 3 speichert, und die vCPU-Worlds in esxtop lassen sich, in Prozent umgerechnet, direkt mit einem Schwellenwert je vCPU vergleichen. Das Übersichtsdiagramm CPU (%) zeigt Ready in Prozent, und die Dokumentation zu vSphere 8.0 nennt den Wert „die durchschnittliche CPU-Ready-Zeit aller virtuellen CPUs der virtuellen Maschine“, gibt aber keine Formel an und sagt nicht, ob er durch die Zahl der vCPUs geteilt wird; ziehen Sie für Vergleiche mit Schwellenwerten daher das erweiterte Diagramm oder esxtop heran.

Diagramme über längere Zeiträume mitteln kurzzeitige CPU-Konkurrenz heraus. Ein Messpunkt im Diagramm Past month umfasst zwei Stunden, daher erscheinen zehn Minuten mit 20 % je vCPU ohne Ready-Zeit im Rest des Zeitfensters als etwa 1,7 %. vCenter bewahrt die 5-Minuten-Werte standardmäßig einen Tag lang auf; beurteilen Sie die Schwellenwerte daher anhand von 20-Sekunden-Daten oder von diesen Werten.

Ready, Co-Stop und Max limited in esxtop und vCenter

esxtop zeigt dieselben Zähler live auf dem Host, als Prozentsätze jedes Messintervalls. Im CPU-Fenster zeigt V nur virtuelle Maschinen an, und die Zeile jeder VM umfasst alle ihre Worlds; %CSTP und %MLMTD sind dort daher wie %RDY Summen für die VM. Mit e erweitert, teilt sich die Zeile in diese Worlds auf, deren Prozentwerte die Dokumentation als „Prozentsatz einer einzelnen physischen CPU“ angibt.

Referenz zur vSphere Web Services API 8.0 und 9.0 (CPU-Zähler); Dokumentation zu vSphere 8.0, CPU-Fenster von esxtop (16. September 2026); KB 438023.

Weil esxtop %MLMTD in %RDY mitzählt, zeigt eine VM, die durch ein CPU-Limit zurückgehalten wird, Ready-Zeit, auch wenn der Host Kerne frei hat; für diesen Fall rät die vSphere-Dokumentation, das Limit anzuheben. Dieselbe esxtop-Seite nennt %CSTP eine Statistik, die „nur für die Verwendung durch VMware vorgesehen“ ist, obwohl KB 438023 und KB 326296 beide einen Schwellenwert dafür angeben.

Broadcoms API-Referenz ordnet Ready der Statistikebene 1 zu, die laut der Dokumentation zu vSphere 8.0 der Standard für jedes Erfassungsintervall ist, und die Zähler Co-stop und Max limited der Ebene 2. Mit der Standardebene zeigt die Historie die Ready-Zeit, nicht aber die Zähler, die sie erklären.

Schwellenwerte für CPU Ready und woher sie stammen

Broadcoms Dokumente nennen Schwellenwerte für mehrere Zähler, hier so aufgeführt, wie die Quellen sie angeben.

Broadcom KB 438023 (ESXi 8.0), KB 326296 (ESXi 5.x bis 8.x), Dokumentation zu vSphere 8.0 (16. September 2026), Performance Best Practices for VMware vSphere 9.0 (Revision 20250731) und 8.0 Update 1 (Revision 20230518).

KB 438023 ergänzt: „Anhaltend hohe Ready-Zeit deutet im Allgemeinen eher auf CPU-Konkurrenz auf Host-Ebene hin als auf eine Unterdimensionierung der einzelnen VM.“ Mehr vCPUs für eine solche VM beseitigen die Konkurrenz nicht, die sie warten lässt.

Die Werte aus KB 438023 gelten je vCPU und für jeden Zähler für sich, während die 20 % aus der Diagrammdokumentation nur bei einer Nutzung über 90 % gelten. Dieselbe Seite wertet eine kurze Spitze bei Ready als Zeichen, dass die Ressourcen der VM gut genutzt werden; vergleichen Sie daher anhaltende Werte.

Co-Stop, NUMA und VMs mit zu vielen vCPUs

Co-Stop betrifft nur VMs mit mehr als einer vCPU (KB 438023). Warum ESXi vCPUs derselben VM zurückhält und wie Sie eine VM anhand gemessener Spitzen richtig dimensionieren, steht in unserem Leitfaden zur Verschwendung in vSphere-Umgebungen.

Überzählige vCPUs kosten auch ohne Co-Stop etwas, wie Broadcoms Best-Practices-Leitfaden festhält: „Wird eine virtuelle Maschine mit mehr virtuellen CPUs (vCPUs) konfiguriert, als ihre Arbeitslast nutzen kann, kann dies zu einer leicht erhöhten Ressourcennutzung führen und auf sehr stark ausgelasteten Systemen möglicherweise die Leistung beeinträchtigen.“

Auf NUMA-Systemen hält ESXi die vCPUs und den Arbeitsspeicher jeder VM innerhalb eines physischen Knotens, wenn die VM klein genug ist, um hineinzupassen (KB 438023), und laut der vSphere-Dokumentation zur Ressourcenverwaltung sind die vCPUs „darauf beschränkt, auf dem Home-Knoten zu laufen, um die Speicherlokalität zu maximieren“. Eine VM kann daher auf die Kerne ihres Home-Knotens warten, während ein anderer Knoten freie Kerne hat, bis der NUMA-Scheduler ihren Home-Knoten wechselt, was er tun kann, „um auf Änderungen der Systemlast zu reagieren“.

Eine VM mit mehr vCPUs, als ein Knoten Kerne hat, erstreckt sich über mehrere Knoten (KB 438023), und ab neun vCPUs stellt ESXi ihrem Gast standardmäßig eine vNUMA-Topologie bereit (Dokumentation zu vSphere 8.0). Für solche breiten VMs rät die KB, die vCPUs gleichmäßig auf möglichst wenige Knoten zu verteilen und ihre Zahl auf höchstens die Zahl der physischen Kerne des Hosts zu begrenzen. Im Arbeitsspeicherfenster von esxtop zeigt NHN den aktuellen Home-Knoten einer VM, und ein eigenes Feld zeigt, welcher Anteil ihres Arbeitsspeichers lokal ist.

Das Verhältnis von vCPU zu pCPU und CPU-Overcommitment

Das Verhältnis von vCPU zu pCPU ist die Zahl der vCPUs der eingeschalteten VMs auf einem Host oder Cluster, geteilt durch dessen physische Kerne. Broadcoms Leitfaden Performance Best Practices for vSphere 9.0 schreibt wie die Ausgabe für 8.0 Update 1, dass ESXi in den meisten Umgebungen eine volle CPU-Zuweisung erlaubt, also so viele vCPUs, wie der Host physische Kerne hat, „und sogar ein erhebliches Maß an CPU-Overcommitment (mehr vCPUs auf einem Host zu betreiben, als dieser Host insgesamt physische Prozessorkerne hat), ohne die Leistung virtueller Maschinen zu beeinträchtigen“. Für einen Host, dessen CPU gesättigt ist, warnt der Leitfaden, „die Leistung einiger oder aller virtuellen Maschinen auf diesem Host könnte erheblich sinken“, insbesondere bei latenzempfindlichen Workloads.

Zählen Sie wie diese Definition physische Kerne, nicht Hyper-Threads. In esxtop ist eine PCPU bei aktivem Hyperthreading eine logische CPU (Dokumentation zu vSphere 8.0), die Zahl der PCPUs liegt dann also über der Zahl der Kerne. Auch VVF und VCF werden auf physischen Kernen lizenziert, auf jedem Kern, ob genutzt oder nicht, wie unser Leitfaden zur VMware-Lizenzierung nach Broadcom erklärt.

Ein Broadcom-Dokument, das einen allgemeinen Zielwert für das Verhältnis festlegt, haben wir nicht gefunden. Die Ready-Zeit hängt davon ab, wie ausgelastet die vCPUs sind, und ebenso davon, wie viele es sind; zwei Hosts mit 4 vCPU je Kern können daher sehr unterschiedliche Ready-Zeiten zeigen, der eine mit wenig genutzten Anwendungsservern, der andere mit Batch-Jobs, die jede vCPU auslasten. Nutzen Sie das Verhältnis zur Planung und Ready je vCPU zur Prüfung: Tragbar ist für einen Host das Verhältnis, bei dem Ready und Co-Stop je vCPU in seiner Stunde mit der höchsten Last unter den Werten aus KB 438023 bleiben. Für gehostete Kapazität beschreibt unser Leitfaden dazu, was dedizierte vCPU und RAM in einem IaaS-Angebot bedeuten, die Seite des Anbieters.

Die Ursache hoher CPU-Ready-Zeit finden

Bleibt Ready je vCPU über etwa 5 %, prüfen Sie die Zähler in dieser Reihenfolge, da jeder Schritt eine Ursache ausschließt.

1. Erfassen Sie die langsame Phase, während sie auftritt, im vCenter-Diagramm Realtime mit 20-Sekunden-Auflösung oder in esxtop auf dem Host mit V, und rechnen Sie Ready je vCPU aus.
2. Vergleichen Sie %MLMTD mit %RDY; entfällt der größte Teil der Ready-Zeit auf Max limited, heben Sie das CPU-Limit, das die VM zurückhält, an oder entfernen Sie es.
3. Prüfen Sie %CSTP, da Co-Stop über etwa 3 % je vCPU auf zu viele vCPUs hindeutet; KB 326296 senkt die Zahl jeweils um eine vCPU, bei ausgeschalteter VM.
4. Prüfen Sie die PCPU-Nutzung des Hosts und den Load Average in esxtop, die Broadcoms Best Practices bei 90 % als Warnung und ab 1 als Überlastung werten; zeigen auch andere VMs auf dem Host Ready-Zeit, verlagern Sie Last mit DRS oder ergänzen Sie Hosts, wie es die vSphere-Dokumentation vorschlägt.
5. Prüfen Sie die NUMA-Platzierung im Arbeitsspeicherfenster, wo eine breite VM mit geringem Anteil an lokalem Arbeitsspeicher oder mehrere große VMs mit demselben Home-Knoten dafür sprechen, die Größe der VMs am Knoten auszurichten.
6. Sehen Sie sich Prioritäten zuletzt an, da CPU-Anteile und -Reservierungen, die die vSphere-Dokumentation für VMs mit hoher Priorität aufführt, einer VM Vorrang vor den anderen auf dem Host geben.

Unser Infrastruktur-Audit erfasst Cluster und ihre tatsächliche Ressourcennutzung anhand der Exporte, die Sie bereitstellen. Schicken Sie uns die Ready- und Co-Stop-Werte der VMs, die Ihre Nutzer als langsam bezeichnen, mit der Zahl ihrer vCPUs.

CPU Ready in einem Plan zur Host-Konsolidierung

Konsolidierung erhöht das Verhältnis absichtlich. Werden dieselben VMs von sechs Hosts auf vier gleich große verlegt, steigt die Zahl der vCPU je Kern um die Hälfte, wie in unserem durchgerechneten Beispiel zur Host-Konsolidierung bei Lizenzierung pro Kern.

CPU Ready zeigt, ob das höhere Verhältnis die VMs bremst. Zeichnen Sie Ready und Co-Stop je vCPU der größten und am stärksten ausgelasteten VMs über das Zeitfenster auf, nach dem der Cluster dimensioniert wird, in 5-Minuten-Auflösung, und vergleichen Sie das 95. Perzentil mit den Werten aus KB 438023. Ein Cluster, dessen größte VMs zum Monatsende bereits zwischen 5 % und 10 % liegen, hat weniger Spielraum, Kerne abzugeben, als seine CPU-Nutzung vermuten lässt. Prüfen Sie nach dem Umzug dieselben VMs zum nächsten Monatsende, bevor die alten Hosts den Cluster verlassen.

Im Rahmen der VMware-Optimierung konsolidiert unser Engineering-Partner Vixen.UNO Hosts und Cluster in vereinbarten Wartungsfenstern, mit einem Rollback-Plan für jede Etappe. Schreiben Sie uns Ihren Cluster-Aufbau und Ihre Spitzenzeiten über das Formular unten.

Was wir tun

Eurokommerz hält den Vertrag und liefert Hardware und Lizenzen; die technische Umsetzung übernimmt unser Engineering-Partner Vixen.UNO. Im Rahmen der VMware-Optimierung auditiert das Vixen.UNO-Team die Umgebung einschließlich ihrer tatsächlichen Ressourcennutzung, stimmt Editionen und Abonnements auf Ihre realen Workloads ab und konsolidiert Hosts und Cluster; gibt es nichts zu optimieren, sagen wir das. Unser Infrastruktur-Audit, ein eigenständiges Produkt mit Festpreis, arbeitet mit den Unterlagen und Exporten, die Sie bereitstellen, ohne Zugriff auf Ihre Produktivsysteme. Das erste Gespräch ist kostenlos; der Preis des technischen Assessments steht vor Beginn fest.

FAQ