ESXi - VMs lasten die Host CPU nur zu 90% aus

[Acid-Beatz]

Hallo zusammen,
mir ist da mal wieder eine Kleinigkeit aufgefallen, nachdem diese Woche der Testbetrieb unter Volllast begonnen hat - vielleicht am Anfang noch ein paar Eckpunkte zur Umgebung:

OS: vSphere 6/ESXi
Hardware: 2x 18 Kerne Haswell-Kerne/512GB RAM pro Host

GastOS: CentOS 7.2

Die Linux VMs sind jeweils mit 12 Kernen und 32 GB RAM ausgestattet, was sich bei 36 CPUs anbietet.

Die VMs sind von der Ausstattung zu 100% identisch, die zu bearbeitenden Daten ebenfalls - eine VM holt sich also einen Datensatz und ackert diesen schnellstmöglich durch.

Vorher bin ich aber über etwas gestolpert, was mich etwas verwundert hat - die Screenshots findet ihr im Anhang - die VMs scheinen bei 90% Belastung des Hosts an eine Art Grenze zu stoßen - rechnet die eine ein bisschen weniger, steigt die Leistung der anderen und vice versa. (Vorsicht, die Zeitskalen der beiden Diagramme sind um ca 5 Minuten versetzt, zumal die dritte VM auf dem Blade fehlt - hier sieht man aber auch nichts anderes.)
Was man aber sehr gut sehen kann, ist die 90% Grenze von der ich Spreche - mehr als 90% der Leistung wird nie an die VMs vergeben, auch wenn diese drei in der Summe 100% des Servers zugewiesen bekommen haben (müssten). Bezüglich des Overheads für den Hypervisor bin ich mir auch bewusst, wobei mir 10%, beziehungsweise 3,6 Kerne doch extrem viel vorkommen und ich glaube, dass VMware die 100% sowieso auf den "Payload" bezogen hat.


Irgendwelche Ratschläge und Ideen? Danke!

[drdope]

--> https://www.vmware.com/files/de/pdf/vsphere-esxi-vcenter-server-601-resource-management-guide.pdf
Hast du manuell in das Ressourcenmanagement eingegriffen?

Wenn ich nicht gerade vollkommen auf den Schlauch stehe, müßtest du eigentlich weit mehr freie CPU-Ressourcen haben, weil deine 2x 18 Kerne ja auch noch Hyperthreading bieten = 36echte und 36virtuelle Cores = 72 Cores ingesamt...

[Acid-Beatz]

Hey,
Danke für Deine Antwort:
--> https://www.vmware.com/files/de/pdf/vsphere-esxi-vcenter-server-601-resource-management-guide.pdf
Hast du manuell in das Ressourcenmanagement eingegriffen?
Nein, erfahrungsgemäß läuft es (ausnahmsweise wirklich) am besten, wenn man die Finger von manuellen Eingriffen lässt, außer es ist wirklich nötig (z.B Lizenzpolitik)!


Wenn ich nicht gerade vollkommen auf den Schlauch stehe, müßtest du eigentlich weit mehr freie CPU-Ressourcen haben, weil deine 2x 18 Kerne ja auch noch Hyperthreading bieten = 36echte und 36virtuelle Cores = 72 Cores ingesamt...
vSphere belegt als erstes alle echten CPU Kerne und steigt dann auf HT um, diese HT Kerne bekommen bei der Berechnung dann statt 1.0 irgendeinen kleineren Faktor zugewiesen (irgendwo hat man es ganz schön gesehen, wenn man bisschen mit den Zahlen gespielt hat).

Da wir uns aber sowieso auf die 36 echten Kerne beschränken kann man dieses Thema außen vorlassen.


Greez

[drdope]

Ich hätte jetzt darauf getippt, daß die HT-kerne mit einem sehr kleinen Faktor arbeiten, aber wenn ihr euch auf reale Cores beschränkt ergibt das wenig Sinn.

Ich würd' einfach mal den vSphere-Support kontaktieren, bevor wir hier Rätsel raten spielen.
Die Jungs an der Hotline sind meiner Erfahrung nach relativ fit (und sitzen nicht in einem CC in Indien).

[The_Invisible]

Sorry für OT aber: Wie (gut) geht ESXi eigentlich mit der NUMA Problematik um? Gut, bei 12 Cores und nur 32GB RAM bei dieser Maschine sollte es nicht das Problem sein. Pinnt VMware die CPUs und Speicher automatisch?

Sind derzeit auf KVM und bin interessiert wie VMware das so macht.

[Brechreiz]

ich würde überdenken ob es Dicke 12 vcpu VM's sein müssen.
Virtualisierung lebt doch davon mehrere VM's laufen zu lassen.

Ebenso erscheint mit 12 vcpu bei einem 18 Kerne umschön. Da kann nur eine VM die richtigen Kerne voll belegen, die nächste muss sich schon in den HT Teilen tummeln. Verteile doch besser, so es RAM seitig möglich ist, besser nur mit 6vcpu. Beachte, der CPU Scheduler von VM-Ware braucht immer 12 freie CPU's für den Workload der einzelnen VM's.

[myMind]

Deckt sich die Grafik mit dem was esxtop anzeigt?

[Acid-Beatz]

Hallo zusammen!


Ich würd' einfach mal den vSphere-Support kontaktieren, bevor wir hier Rätsel raten spielen.
Die Jungs an der Hotline sind meiner Erfahrung nach relativ fit (und sitzen nicht in einem CC in Indien).
So dumm es klingt, auf die Idee bin ich noch garnicht gekommen :freak:


Sorry für OT aber: Wie (gut) geht ESXi eigentlich mit der NUMA Problematik um? Gut, bei 12 Cores und nur 32GB RAM bei dieser Maschine sollte es nicht das Problem sein. Pinnt VMware die CPUs und Speicher automatisch?

Sind derzeit auf KVM und bin interessiert wie VMware das so macht.
Ich bin mir gerade nicht sicher, ob ich dich richtig verstanden habe, ansonsten korrigiere mich bitte noch mal:
Deine Frage ist, wie gut VMware es im Griff hat CPUs und den dazugehörigen Hauptspeicher zusammen zu halten? Reicht Dir als Antwort ein: "Funktioniert bis auf wenige Ausnahmen so weit sehr gut und ohne große Performanceeinbußen".
Hast Du einen konkreten Fall, wo man das überprüfen kann?

ich würde überdenken ob es Dicke 12 vcpu VM's sein müssen.
Virtualisierung lebt doch davon mehrere VM's laufen zu lassen.

Ebenso erscheint mit 12 vcpu bei einem 18 Kerne umschön. Da kann nur eine VM die richtigen Kerne voll belegen, die nächste muss sich schon in den HT Teilen tummeln. Verteile doch besser, so es RAM seitig möglich ist, besser nur mit 6vcpu. Beachte, der CPU Scheduler von VM-Ware braucht immer 12 freie CPU's für den Workload der einzelnen VM's.
Ein Host hat 2*18 = 36 echte Kerne, wodurch man darauf genau 3 VMs a 12 Kerne unterbringen kann, zumindest in der Theorie.
Ich weiß, dass es seitens VMware die Empfehlung gibt möglichst kleine VMs zu bauen - wir sind hier aber auf die Rechenleistung angewiesen und hier wurden in Tests 12 vCPUs als guter Kompromiss festgestellt, ansonsten hätten wir viel zu viele VMs (aktuell knappe 50, bei 6 CPUs dementsprechend 100 - Tendenz steigend.)
Da die einzelnen VMs nur als "Nodes" weiterer Software fungieren, müsste dann noch an vielen weiteren Stellen Hand angelegt werden.


Da kann nur eine VM die richtigen Kerne voll belegen, die nächste muss sich schon in den HT Teilen tummeln
Hast Du dafür eine Quelle?
Ich bin mir ziemlich sicher in einer Dokumentation von VMware gelesen zu haben, dass als erstes alle physischen Kerne aufgefüllt werden und erst dann HT zum Einsatz kommt.

Deckt sich die Grafik mit dem was esxtop anzeigt?
Kann es da zu Unterschieden kommen? Ich dachte die Graphen sind eben genau eine Visualisierung dessen, was esxtop liefert?


Vielen Dank Euch!

[myMind]

Kann es da zu Unterschieden kommen? Ich dachte die Graphen sind eben genau eine Visualisierung dessen, was esxtop liefert?

Ungefähr so wie ein Oszilloskop das selbe anzeigt wie ein Multimeter.

Ich würde mal einen reinen CPU-Load-Test wie Prime95 ausführen.

[Lokadamus]

Das hat einer für ESXi 5.5 geschrieben, dürfte sich mit der neuen Version decken.
https://www.cristie.co.uk/media/2160/perf_best_practices_vsphere55.pdf
The usage percentage for the physical CPUs on the pCPU line can be another in dication of a possibly overloaded condition. In general, 80% usage is a reasonable ceiling and 90% should be a warning that the CPUs are approaching an overloaded condition. However organizations will have varying standards regarding the desired load percentage.

[Acid-Beatz]

Ungefähr so wie ein Oszilloskop das selbe anzeigt wie ein Multimeter.

Ich würde mal einen reinen CPU-Load-Test wie Prime95 ausführen.

Hallo zusammen,
eigentlich wollte ich mich ja schon eher wieder melden, hatte wegen vielen anderen Sachen aber keine Zeit und wie das oft so ist, hat mir ein Kollege das Testen gespart, nachdem er seine "Real-World" Applikation angeworfen hat:

Der Graph zeigt die Belastung des Hosts, der mit einer einzelnen 36 Kerne VM arbeitet, die RAM Auslastung beträgt rund 480GB, wenig weiterer IO.
Die Anwendung ist eine Eigenentwicklung und hauptsächlich auf RAM und FPU angewiesen.

The usage percentage for the physical CPUs on the pCPU line can be another in dication of a possibly overloaded condition. In general, 80% usage is a reasonable ceiling and 90% should be a warning that the CPUs are approaching an overloaded condition. However organizations will have varying standards regarding the desired load percentage.
Ich gehe davon aus, dass VMware das unter "normalen" Bedingungen voraussetzt - 20 % Buffer für weitere VMs, die Leistungsmäßig noch anspringen könnten, nicht für vollbelastete Blades mit einzel VMs, beziehunsweise Blades ohne (SIC!) "Overprovisioning".


Der ein oder andere mag jetzt sicher auch fragen, wozu man den ganzen Aufwand mit Virtualisierung betreibt, wenn man ein Blade sowieso auslastet: Wir sind dabei es auszuprobieren - gewissermaßen from the Scratch in unserem Umfeld.
Wir bieten Projekten die Rechenleistung, wenn die eigene Hardware nicht mehr ausreicht und sie mal für ein halbes Jahr 20 VMs a 10 Kerne brauchen.
Bei oben genanntem Projekt wird es noch einen zweiten "Rechenlauf" ohne Virtualisierung geben, dann wird entschieden, ob gegebenenfalls noch mal 10 - 20 solcher Blades ins Haus kommen und wie man diese betreiben wird - Testphase eben, wo man hier und da schauen muss.


Vielen Dank für weiteren Input oder Anregungen!

[Lokadamus]

Ich gehe davon aus, dass VMware das unter "normalen" Bedingungen voraussetzt - 20 % Buffer für weitere VMs, die Leistungsmäßig noch anspringen könnten, nicht für vollbelastete Blades mit einzel VMs, beziehunsweise Blades ohne (SIC!) "Overprovisioning".

Vielen Dank für weiteren Input oder Anregungen!Overprovisionig ist ein gutes Stichwort für Google im Zusammenhang mit VMWare.

Das hört sich interessant an. Vielleicht kannst es mal durchlesen und deine Meinung dazu sagen.
https://communities.vmware.com/servlet/JiveServlet/previewBody/21181-102-1-28328/vsphere-oversubscription-best-practices%5B1%5D.pdf
Edit: Ist allerdings für VMWare 4.1 geschrieben, ist eventuell nicht mehr aktuell.

https://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.5.pdf <-- neuere Fassung als der Link aus dem älteren Beitrag? :|

Edit: Was mir gerade noch eingefallen ist.
Du bräuchtest 2 Testmaschinen, um das Verschieben zu testen. Ich meine, das kann automatisiert passieren. Dann überprüfen die Hosts selber, wie stark sie ausgelastet sind und versuchen durch verschieben der VMs die Last auszugleichen.
Dabei fällt mir noch ein anderer Vorteil ein. Du hast weniger Probleme, wenn du mal die Hardware austauscht. Die VM kann verschoben werden, aber wenn die Kiste physikalisch läuft, musst du selber überlegen, wie die Daten von Kiste a nach Kiste b kommen (Spiegeln, Ex- und Import der Daten usw.).
Allerdings dürfte beim Verschieben das Overcommiting bzw. Overprovisioning relevant werden. Ist dies der Fall, müsste das Verschieben geblockt sein, weil die Kiste zu schwer am werkeln ist.

[Acid-Beatz]

Overprovisionig ist ein gutes Stichwort für Google im Zusammenhang mit VMWare.

Das hört sich interessant an. Vielleicht kannst es mal durchlesen und deine Meinung dazu sagen.
https://communities.vmware.com/servlet/JiveServlet/previewBody/21181-102-1-28328/vsphere-oversubscription-best-practices%5B1%5D.pdf
Edit: Ist allerdings für VMWare 4.1 geschrieben, ist eventuell nicht mehr aktuell.

https://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.5.pdf <-- neuere Fassung als der Link aus dem älteren Beitrag? :|

Hey Loka,
Danke für Deine Antwort - ich habe Google durchaus schon einige Male zu dieser Thematik befragt, bin auf keinen Grünen Zweig gekommen, weil die Workloads immer komplett andere waren, als wir sie fahren.
In meinen Augen sind die VMware Performance Guides auch eher allgemein gültige, als speziell auf VMware zugeschnitten - zu viele CPUs haben bei anderen Virtualisierern die gleichen negativen Auswirkungen.

Und wenn man sowas liest, dann scheinen sich die Guides wirklich an Leute zu richten, die auf eine 36 Kerne System dank HT und der guten Technik 130+ an Kernen daraufpacken und sich anschließend über die Performance wundern - hierzu zähle ich mich nicht, trotz meiner Fragen hier ...

In most environments ESXi allows significant levels of CPU overcommitment (that is, running more
vCPUs on a host than the total number of physical processor cores in that host) without impacting virtual
machine performance.
If an ESXi host becomes CPU saturated (that is, the virtual machines and other loads on the host demand
all the CPU resources the host has), latency-sensitive workloads might not perform well. In this case you
might want to reduce the CPU load, for example by powering off some virtual machines or migrating
them to a different host (or allowing DRS to migrate them automatically).



Nächster Schritt wird dann die Analyse mit ESX-Top sein, hier muss ich mich noch mal einlesen und die Entwickler dazuholen, die oft auch interessante Einblicke geben können ... (wir hatten auch schon den Fall, dass mit der Materie nicht ganz so fitte Kollegen viel zu Große Datensätze gewählt haben, was dann in Swapping mit der entsprechenden Performance geendet ist :rolleyes:

[Lokadamus]

In meinen Augen sind die VMware Performance Guides auch eher allgemein gültige, als speziell auf VMware zugeschnitten - zu viele CPUs haben bei anderen Virtualisierern die gleichen negativen Auswirkungen.

Und wenn man sowas liest, dann scheinen sich die Guides wirklich an Leute zu richten, die auf eine 36 Kerne System dank HT und der guten Technik 130+ an Kernen daraufpacken und sich anschließend über die Performance wundern - hierzu zähle ich mich nicht, trotz meiner Fragen hier ...

Nächster Schritt wird dann die Analyse mit ESX-Top sein, hier muss ich mich noch mal einlesen und die Entwickler dazuholen, die oft auch interessante Einblicke geben können ... (wir hatten auch schon den Fall, dass mit der Materie nicht ganz so fitte Kollegen viel zu Große Datensätze gewählt haben, was dann in Swapping mit der entsprechenden Performance geendet ist :rolleyes:Weil sich vieles auf andere Virtualisierer übertragen lässt.

Im Prinzip wäre das kein Problem, die Sache ist nur dass die VMs entweder begrenzt werden oder die Kisten wirklich keine Performence fressen. Dann kann man mehr CPUs an VMs verteilen als man wirklich hat. Laufen die VMs mal wirklich auf max. Perf wird es dabei übel.

In einem ordentlichen Test werden sollten auch die max. Werte ausgelotet. Nachher ist das Prob, dass ihr HDDs mit 10k RPM genommen habt anstatt 15k oder SSDs. ;)