Viele vCPUs in virtuellen Maschinen.
vmware kann in vSphere 5.1 bis zu 64! vCPUs. Macht das aber auch Sinn? Welche Beschränkungen gibt es und was sollte man vermeiden bzw. beachten?
Ein paar Informationen und Ideen zu diesem, in letzter Zeit auch an anderen Stellen dirskutiertem Thema sollen etwas Licht ins Dunkel bringen.
vCPU Overcommitment in vmware vSphere 5.1
Grundsätzlich ist es möglich in vmware vSphere Umgebungen in Summe mehr vCPUs an VMs zu vergeben als physikalisch vorhanden sind. vCPUs haben aber ein paar besonderheiten z.B. gegenüber dem vordem behandelten Memory Overcommitment.
Beschränkungen:
- Man kann nicht mehr vCPUs an eine VM vergeben als physikalische Cores vorhanden sind!
- Die VM sieht den Typ der physikalischen CPU – (vMotion, DRS relevant)
- Auf Intel Systemen kann Hyperthreading verwendet werden. Hyperthreading bedeutet aber nicht doppelt so viele CPUs bzw. Cores!
- Mehrere Cores in einer VM bedeutet keinen Performancegewinn, sondern dient nur dazu Applikationen die mehrere Cores verlangen in einer VM betreiben zu können.
Die einzelnen Themen möchte ich hier ein wenig näher erläutern.
Simultan Multiprozessor Systeme – VMs mit mehreren vCPUs
vmware unterstützt Simultan Multiprozessor Systeme [SMP] als VMs. Theoretisch sind bis zu 64 vCPUs in entsprechenden Hosts möglich. Nur was macht der vmkernel und was macht auch praktisch Sinn?
Der vmkernel als Ressourcenverwalter versucht, alle vCPUs einer VM auch auf einem Sockel zu halten. Hintergrund sind die Controller auf dem CPU Sockel. Diese sind effizienter im Verteilen von Threads auf mehrere Cores eines Sockel als der Board Chipsatz, wenn dieser auf mehrere Cores unterschiedlicher Sockel verteilen soll.
Daraus ergibt sich folgendes Bild
Fall A stellt den Best Praktice Fall dar. Alle vCPUs der 4 CPU VM sind auf einem Sockel und der vmkernel versucht diese auch hier zu halten.
Fall B stellt den „schlechteren“ Fall dar. der vmkernel muß die vCPUs einer 6 CPU VM auf min. zwei Sockel verteilen. Dieses ist definitiv uneffizienter.
Fazit: Nie mehr vCPUs pro VM als Cores auf einem Sockel! – Best Praktice
Mehr vCPUs gleich weniger VM CPU Performance? Hintergrund
Ein weiterer Umstand der Virtualisierung kann dazu führen, das VMs mit mehr CPUs langsamer arbeiten, als solche mit weniger CPUs.
„Viel hilft viel – gilt also nicht immer“
Zu diesem Umstand sollten wir kurz überlegen was Virtualisierung für die physikalischen CPUs bedeutet, bzw. was der vmkernel so anstellt.
Im Prinzip haben wir es bei der Virtualisierung mit einen geschedulten System zu tun. Dieses bedeutet, das sich viele VMs mit vielen vCPUs um Bearbeitungsslots auf den physikalischen Cores streiten. Verteiler ist der vmkernel.
Haben wir nun z.B. eine 4 vCPU VM muß der vmkernel vier freie Slots finden um die VM bedienen zu können. Bis zu einem gewissen Grad ist dieses kein Problem und wir nicht „gefühlt“. Haben wir aber plötzlich eine VM mit zum Beispiel 12 vCPUs auf einem Host der mehrere 1 vCPU und 2 vCPU VMs beherbergt, dann wird die 12 vCPU sehr wahrscheinlich oft auf 12 parallele Slots warten müssen. Genau das führt dann zu hohen „CPU.Ready“ Werten. Diese VM kann unter Umständen mit nur 6 vCPUs deutlich schneller arbeite.
Hier ist einfach Monitoring und Auswerten von Messwerten notwendig um geg. die optimale vCPU Anzahl zu ermitteln.
Siehe hier auch: „How too many vCPUs can negatively affect performance“ (http://www.gabesvirtualworld.com)
Hyperthreading auf Intel Hosts – Fallstricke!
Was ist Hyperthreading und was bringt es? Hyperthreading ist eine Lösung von Intel um die Cores eines Sockels effizienter auszulasten und somit „CPU-Gewinn“ zu erzielen.
Theorie dazu: Eine moderne CPU besteht nicht nur aus einem stumpfen „Befehlsabrbeiter“, sondern jede Vorverarbeitung in der CPU schaut in die Instruction Pipe der CPU welche Befehle als nächstes anstehen. Diese werden dann möglichst effizient im CPU oder Core Cache sortiert.
Im Bild oben versuche ich dieses LowLevel darzustellen. Die dicken grünen Pfeile stellen die Instruction Pipes dar, das Oval den zugehörigen Cache.
Dieses Verfahren bringt (Aussage eines Intel Kenners) bis zu 30% CPU Gewinn. Somit sollte Hyperthreading durchaus eingeschaltet werden.
Fallstrick: Nun gibt es aber Sonderfälle in welchen Hyperthreading genau kontraproduktiv wirkt!
Wenn eine VM zum Beispiel Applikationen mit Audio Codecs, oder anderen „Echtzeit“ bzw. nahezu Echtzeit Systemen enthält, wirkt unter Umständen Hyperthreading nicht als Gewinn, sondern als Verzögerung. Verursacher ist dabei das Zusammenspiel zwischen Hyperthreading Cache und vmkernel. Der vmkernel prüft ca. alle 20ms die Auslastung der einzelnen Cores. Nun kann es passieren das der vmkernel vCPUs von einer logischen CPU auf eine anderen verschiebt. Dabei geht dann, je nach Situation, der Hyperthreading Cache „verlohren“. Haben nun die VMs mit den Codecs mehr als eine vCPU und die Last auf dem Host wächst, kann es passieren das Hyperthreading mehr mit dem Aufbau des Caches als mit der Effizienz durch diesen Cache beschäftigt ist. Somit wirkt Hyperthreading kontraproduktiv. In diesen Fällen hilft nur Abschalten.
Wie bereits gesagt handelt es sich hier um Spezialfälle. In den meisten Umgebung ist Hyperthreading ein Gewinn und kann problemlos verwendet werden.
dervirtuellewirt 
