CPU Ready und CPU Co-STOP

Bei der Kontrolle der Leistungsdaten eines ESXi Servers (vSphere-Client – Performance – Realtime) fiel mir ein unglaublich hoher Wert für CPU-Ready auf. Laut Graph war dort ein Wert von fast 23 Sekunden. Wie kann das sein?

Bevor man die Werte deutet, sollte man zunächst einige Bergriffe definieren.

CPU-Ready

Angabe in Prozent (%RDY) oder in Millisekunden (ms). CPU-Ready bezeichnet die Zeit, die eine VM warten muß bis ihrer vCPU eine physische CPU zugeteilt wird.

VM bereit – Host nicht.

Co-Scheduling

Hat eine VM mehr als eine vCPU, so müssen diese zeitgleich physischen CPU Kernen des Host Systems zugeordnet werden. Das bedeutet im Klartext, eine VM mit einer vCPU muß warten bis ein Kern frei ist. Eine VM mit 4 vCPU muß entsprechend warten bis 4 Kerne gleichzeitig frei sind. Letzteres ist wesentlich weniger wahrscheinlich. Und damit sind wir auch beim dritten Schlagwort: Co-Stop.

Co-STOP

Zeit, die eine VM bereit ist, jedoch aufgrund von Wartezeiten durch Co-Scheduling nicht einem physischen Kern zugeteilt werden kann. Im Prinzip das selbe wie CPU-Ready, jedoch für VMs mit Virtual Symetric Multiprocessing (vSMP). Während hohe CPU-Ready Werte auf ein Hostsystem unter Druck schließen lassen, kann man dies bei hohen Co-STOP Werten nicht unbedingt folgern. Es bedeutet nur, daß der Host nicht die geforderte Anzahl physischer Kerne gleichzeitig bereitstellen kann.

Beispiel: Ein Host mit dual Quad-Core CPU hat acht logische Kerne. Meine Beispiel-VM (VM1) hat 6 vCPU. Selbst wenn der Host zu einem gegebenen Zeitpunkt 5 freie Kerne bietet, kann VM1 nicht bedient werden. So entstehen Co-STOP Zeiten. Die gleiche VM mit nur 4 oder 2 vCPU würde im gleichen Zeitintervall deutlich häufiger zum Zuge kommen. Der vermeintliche Leistungsvorteil von 6 vCPU verpufft in längeren Co-STOP Zeiten.

Doch nun zurück zum oben genannten Beispiel. Wir sehen bei diesem ESXi Host um 14:51 Uhr einen CPU-Ready Wert von fast 23 Sekunden. Das bedeutet aber nicht, daß zur fraglichen Uhrzeit VMs 23 Sekunden auf eine physische CPU Zuteilung warten mussten, denn das würde einem Totalausfall gleichkommen.

Bei der Grafik handelt es sich um eine Realtime-Metrik. Dabei werden Wartezeiten über ein Messintervall von 20 Sekunden aufsummiert. Die 22.998 Millisekunden sind also die Summe der VM Wartezeiten in einem 20 Sekundenintervall.

Zum fraglichen Zeitpunkt befanden sich 20 VMs mit 27 vCPU auf dem ESX Knoten. Pro VM ergibt sich somit eine Wartezeit von 1.150 ms. Dies ist die Summe aus 20 Sekunden oder 20.000 ms. Prozentual sind das 5,75 %. Werte um die 5% sind ein Warnsignal, Werte über 10% ein ernstes Problem.

Die Tabelle unten beschreibt die Messintervalle der unterschiedlichen Metriken im vSphere-Client.

Metrik	Intervall	Intervall [s]
Realtime	20 s	20
per Day	5 min	180
per Week	30 min	1.800
per Month	2 h	7.200
per Year	1 d	86.400

 

Performance Tipps

• Das Verhältnis pCPU:vCPU auf einem Host sollte nicht mehr als 1:5 sein. Das gilt für VMs mit Single CPU.
• VMs mit vSMP verschieben das pCPU:vCPU Verhältnis zu kleineren Relationen wie 1:4 oder 1:3.
• Der CPU Scheduler bevorzugt alle vCPU einer VM auf den Cores eines Prozessors laufen zu lassen. Ist dies nicht möglich, gehen wichtige Cache Effekte verloren. Daumenregel: Die Anzahl der vCPU einer VM sollte nicht die Anzahl der Cores pro pCPU überschreiten.
• Weniger ist mehr. Einer VM sollten nur dann weitere vCPU zugeteilt werden, wenn es zu CPU Sättigung innerhalb der VM kommt.

 

 

Links:

• vSphere 5 Documentation Center: CPU-Counters
• VMware [PDF]: The CPU Scheduler in vSphere4
• VMware [PDF]: Performance Best Practices for VMware vSphere5
• Gabes World: How too many vCPUs can negatively affect performance
• VMwise: What is co-scheduling anyway?