Getestet: CPU Scheduler Xen, ESXi und Hyper-V

[StefanWe 14]

Hallo,

 

dieser Thread und die Aussage, das Hyper-V nicht alle virtuellen CPU's gleichzeitig belegt hat mich stutzig gemacht und ich wollte einmal alle 3 Hypervisor (XenServer 6.5, Hyper-V Win 2012 R2 und ESXi 5.5 U2) miteinander vergleichen.

 

An gehangen habe ich ein Dokument mit meinen Ergebnissen. Ich musste es zippen, damit ich unter die 512K Grenze komme.

 

Die Aussage mit Hyper-V stimmt. Die Performance ist grandios. Erstaunt bin ich vor allem wie schlecht XenServer, selbst in der aktuellen Version abschneidet.

 

Getestet habe ich mit dem Programm Prime95.

 

Bitte keine Diskussion in Sinne von "Welcher Hypervisor ist der Beste".

 

CPU Scheduler Vergleich.zip

[zahni 554]

Hi, 

 

Deine Bemühungen in Ehren, aber die Ergebnisse lassen sich kaum auf andere Umgebungen übertragen.

Den Prozessor würde niemand in einen Server einbauen (hoffe ich mal). Du solltest  CPU-Technisch  immer Reserven für für den Hypervisor vorhalten. Das geht bei der CPU mit 2 Cores schlecht.

Was meinst Du im Test mit "an eine CPU gebunden"? Greife in der VM-Config bei VMWare nicht in das CPU-Scheduling ein. Da muss man genau wissen was man macht. 

Nicht, dass am Ende im Test immer der gleiche physikalische Core  verwendet wird. 

 

Bei VMWare nimmt Du zur Live-Messung ESXTOP auf der  Console. Bei Hyper-V misst Du die CPU-Last in der Parent-Partition. Die hat auch gerade nichts zu tun. Daher ist  sie niedrig. Du musst die passenden Performance-Counter abfragen:

https://msdn.microsoft.com/en-us/library/cc768535(v=bts.10).aspx

 

Zum HDD-Test: Probiere bei VMWare den PVSCSI aus und verwende zum Test IOMeter mit einem passenden Profil (bei Heise liegt irgendwo eins rum)

Es kommt auf die Anzahl der IOPS und und nicht auf die max. mögliche Übertragungsrate. 

[StefanWe 14]

Hi,

 

die Ergebnisse sollen ja auch nur zeigen, dass es wirklich stimmt, das hyper-v keine Probleme mit CPU locking hat.

 

Trotz relaxed Co scheduling von esxi muss man weiterhin aufpassen wie viele vcpus man seinen vms zuordnet.

Dieses Problem hat Hyper-v nicht.

Ich hab zwar erwartet, dass xenserver hier ähnlich arbeitet wie hyper-v, aber das ist nicht der Fall.

 

Ich habe mich extra für solch eine kleine CPU entschieden, um die Tests zu vereinfachen. Selbst wenn es eine aktuelle 12 Core CPU ist, und ich viele vms mit 4 oder mehr vcpus habe, komme ich irgendwann auf ähnliche Ergebnisse.

 

Ich habe schon einige Kunden Umgebungen unter esxi gesehen, wo im Template 4 vcpus sind und damit alle Vms ausgestattet sind. Die ganze Umgebung läuft langsam, weil sehr hohe Ready Werte vorhanden sind.

Dies wäre also in einer HyperV Umgebung sicher deutlich entspannter gewesen.

 

Auch wenn ich an Vdi Workloads denke, mit einer hohen Anzahl an Vms könnte jeder VM 4 vcpus gegeben werden und sie würden unter HyperV trotzdem schnell laufen.

[NilsK 2.957]

Moin,

 

"wer misst, misst Mist" ... es hat schon einen Grund, dass nahezu kein Hersteller Benchmarks offiziell zulässt. Wenn man es nicht mit wissenschaftlicher Methodik betreibt, kommt man nicht zu validen Ergebnissen.

 

Vielen Dank für deine Mühe, aber wie schon angemerkt, verläuft man sich bei sowas sehr schnell. Daher wäre ich mit Schlussfolgerungen auf Basis deiner Daten sehr vorsichtig.

 

Schöne Grüße, Nils

[zahni 554]

Ich habe schon einige Kunden Umgebungen unter esxi gesehen, wo im Template 4 vcpus sind und damit alle Vms ausgestattet sind. Die ganze Umgebung läuft langsam, weil sehr hohe Ready Werte vorhanden sind.

Dies wäre also in einer HyperV Umgebung sicher deutlich entspannter gewesen.

 

Auch wenn ich an Vdi Workloads denke, mit einer hohen Anzahl an Vms könnte jeder VM 4 vcpus gegeben werden und sie würden unter HyperV trotzdem schnell laufen.

 

Wie Nils schon schrieb: Kann sein, kann auch nicht sein. Hier hängt vieles von der konkreten Umgebung ab (die wir nicht kennen) und auch von Software-Versionen. Auch hat die eine oder andere CPU-Generation oder Baureihe Features, die durchaus nützlich sind. 4 vCPU per default in allen VMs sollte man eh nicht verwenden.

Du solltest von Deinem Testaufbau auf keinen Fall auf andere Umgebungen schließen.

[DocData 85]

Keiner meiner Kunden hat sich je aus Gründen der Performance für oder gegen einen Hypervisor entschieden. Es war zu 75% eine Frage der Betriebskosten und des Ökosystems um den Hypervisor herum. In wenigen Fällen war es eine reine CAPEX Entscheidung. Meist eine Gemengelage aus CAPEX, OPEX und dem verfügbaren Ökosystem.

 

Daher ist der Benchmark zwar nett gemeint, aber nicht auf Basis wissenschaftlicher Methoden entstanden. Daher volle Zustimmung zum Beitrag von NilsK.

[StefanWe 14]

Was meinst Du im Test mit "an eine CPU gebunden"? Greife in der VM-Config bei VMWare nicht in das CPU-Scheduling ein. Da muss man genau wissen was man macht. 

Nicht, dass am Ende im Test immer der gleiche physikalische Core  verwendet wird. 

 

 

Hiermit war gemeint, dass ich im Gast System prime95.exe im Taskmanager über die CPU Affinität an eine vCPU gebunden habe, so dass das Gast System explizit nur eine vCPU zu 100% auslastet.

bearbeitet 22. Juni 2015 von StefanWe

[zahni 554]

Hiermit war gemeint, dass ich im Gast System prime95.exe im Taskmanager über die CPU Affinität an eine vCPU gebunden habe, so dass das Gast System explizit nur eine vCPU zu 100% auslastet.

 UN das könnte ein Problem sein. In der Software kann man doch sowieso festlegen, wie viele Cores/Threads benutzt werden.

[StefanWe 14]

 UN das könnte ein Problem sein. In der Software kann man doch sowieso festlegen, wie viele Cores/Threads benutzt werden.

 

Also ich habe es erst in der Software konfiguriert und anschließend über die Task Manager Affinität. Bei ersterem hatte er trotzdem im Gast beide CPU's genutzt. Erst als ich den Prozess fest an eine CPU im Gast gebunden habe, lief der auch wirklich dort.

 

Performance technisch war es allerdings irrelevant.Die Werte waren die gleichen.

[zahni 554]

Nur für Dich mal auf 'ner richtigen Hardware:

 

Pro CPU 8 echte Cores , ESXI 5.1 U3

 

VM: 6 VPU  16 GB RAM (oder so)

 

Funktion: Benchmark in Prime95

 

result_6_vcpu.txt

[StefanWe 14]

Nur für Dich mal auf 'ner richtigen Hardware:

 

Pro CPU 8 echte Cores , ESXI 5.1 U3

 

VM: 6 VPU  16 GB RAM (oder so)

 

Funktion: Benchmark in Prime95

 

result_6_vcpu.txt

 

Wie viele VM's laufen denn noch auf dem Host?

 

Ist HT aktiviert? Wenn nein, dann lass doch bitte mal parallel eine zweite VM mit 6 Cores laufen und in beiden gleichzeitig Prime95 Benchmark.

[zahni 554]

Nö, keine Zeit. Solche Konstellationen sollten im echten Leben nicht vorkommen. Wenn doch, stimmt etwas am Sizing nicht.

Zumal niemals alle VMs mit Volllast laufen. Derzeit sind in unserem Cluster 225.000 Mhz verfügbar. Davon werden selten mehr als 25.500 Mhz  verwendet.

Mir reicht die Aussage, dass unser Server notfalls auch bis 6 vCPU's skalieren.

 

Was ich Dir sagen kann 2 VMs mit  je 2 vCPU haben keinen Einfluss. Zumal der  Server 2 Prozessoren mit NUMA  hat.

[StefanWe 14]

Nö, keine Zeit. Solche Konstellationen sollten im echten Leben nicht vorkommen. Wenn doch, stimmt etwas am Sizing nicht.

Zumal niemals alle VMs mit Volllast laufen. Derzeit sind in unserem Cluster 225.000 Mhz verfügbar. Davon werden selten mehr als 25.500 Mhz  verwendet.

Mir reicht die Aussage, dass unser Server notfalls auch bis 6 vCPU's skalieren.

 

Was ich Dir sagen kann 2 VMs mit  je 2 vCPU haben keinen Einfluss. Zumal der  Server 2 Prozessoren mit NUMA  hat.

 

Sobald du aber 4 VM's mit 6 vCPU's laufen hast, kommst du auch in das CPU locking Problem.

 

Die VM's müssen ja gar nicht unter Volllast laufen, sobald ein virtueller Kern rechnen muss, müssen 6 physische zur Verfügung stehen, da VMWare nur eine synchrone Abarbeitung kann. 

Ich hätte auch nicht gedacht, das Hyper Threading in diesem speziellen Fall doch so einen starken positiven Einfluss hat. 

 

Mit meinem Test wollte ich überprüfen, ob Hyper-V wirklich "asynchron" die CPU Aufgaben abarbeiten kann. Und das kann es, so wie es aussieht.

bearbeitet 22. Juni 2015 von StefanWe

[zahni 554]

Sobald du aber 4 VM's mit 6 vCPU's laufen hast, kommst du auch in das CPU locking Problem.

 

Die VM's müssen ja gar nicht unter Volllast laufen, sobald ein virtueller Kern rechnen muss, müssen 6 physische zur Verfügung stehen, da VMWare nur eine synchrone Abarbeitung kann. 

 

 

 

Nein, das ist nicht so. Bei VMware gibt es dazu div. Dokumente. Hatte ich mal mal verlinkt. Beschäftige Dich damit, wie VMWare das in aktuellen Versionen macht.

 

Wenn bei uns so etwas auftreten sollte, verteilt Vmotion die VMs auf andere Hosts. 

Sagen wir mal so: Vielleicht hat Hyper-V Deiner speziellen Situation (Überlastung des Hypervisors) einen Vorteil.

Auf der Pro und Contra-Liste ist das aber nur ein Punkt.

 

Edit https://www.vmware.com/files/pdf/techpaper/VMware-vSphere-CPU-Sched-Perf.pdf

 

Lies genau: Dort ist auch beschrieben, warum VMWare manche Dinge so macht, wie sie es machen, 

Und für einen Single.Thread müssen mitnichten alle Core "online" sein.

bearbeitet 22. Juni 2015 von zahni

[DocData 85]

Quintessenz dieses Threads "Mimimi, Hyper-V ist aber besser!!111elf"