ESXi - virtualisiert geringe CPU-Leistung - normal?!

[icebeer]

Hallo zusammen,

ich habe mir kürzlich einen FSC-Server mit 'nem Quad Core als Testsystem zugelegt, um ein bissel mit ESXi und Virtualisierung allgemein zu spielen. Leider musste ich gestern feststellen, dass bei mir virtualisiert insbesondere die CPU-Leistung rapide abnimmt. Ist das normal? Ich dachte, dass die Virtaulisierung nur einen kleinen Impact auf die Performance haben sollte...

Ubuntu 12.10 Server nativ
=> 1048/3017 Punkte im UnixBench

Ubuntu 12.10 Server virtualisiert
=> 532/1374 Punkte im UnixBench

Das sind mal locker 50% weniger Leistung! Sowohl pro Core, als auch insgesamt. Etwas heftig, oder?

HW:
- Intel Xeon E5430 (4x 2.66 Ghz), Virtualisierungsoptionen alle im BIOS an
- 16 GB RAM
- 80 GB Intel SATA SSD

Settings ESXi 5.1:
- 4 vCores
- 6 GB RAM
- ~18 GB von der SSD
- keine weiteren virtuellen Maschinen aktiv/überhaupt konfiguriert
- VMWare Tools installiert auf dem Gast und auf dem neuesten Stand

Hat jemand eine Idee woran der Leistungseinbruch liegen könnte? So macht virtualisieren leider keinen Spaß...

 

[fdsonne]

Hast du irgendwelche Limits gesetzt?
Auch könnten Reservierungen oder ähnliches da rumfuschen.
Hast du noch andere VMs wärend der Benches gestartet?

Grundsätzlich kann ich das Verhalten nicht bestätigen... Denn bei unseren CPUs und unseren Servern geht der Betrieb in einer VM nahezu verlustfrei


EDIT:
was noch zu erwähnen ist. Der E5430 besteht intern aus zwei Dual Core CPUs.
Wie teilst du der VM die CPUs zu?
Machst du das via Cores oder via CPUs?

Auch habe ich festgestellt, das ein Zuweisen aller Ressourcen an eine VM ggf. nicht volle Leistung erziehlt. Speziell bei Core2 CPUs (wie deinem Xeon)
Denn unter der Decke könnte das Problem schlicht sein, dass die Arbeit unnötig oft zwischen den beiden DualCore Teilen der CPU hin und her gewurfen wird. Das passiert dir native auf der Hardware so grundsätzlich nicht.

Was ggf. noch interessant zu teste wäre, drück mal nur eine CPU in die VM und gib dieser zwei Cores. -> Wie verhält sich die Performance an der Stelle?

Ansonsten könnte ggf. noch der RAM mit in die Suppe spucken. FB-Dimm hat grottige Durchsatzraten. Was ggf. die Performance merklich in den Keller drücken kann.

 

[icebeer]

Danke schon mal für deine Antwort.

Ich hatte zu dem Zeitpunkt keiner anderen VMs installiert oder Limits gesetzt. Ich habe ESXi frisch installiert, eine VM erstellt, ihr 4vCores, 6 GB RAM und ausreichend HDD-Platz zugewiesen und dann direkt gebencht. Ich probiere es gleich noch einmal mit nur 2 Cores für die VM aus.

Welchen Einfluss könnten die FB-Dimms nehmen? Ich meine, die sind ja so oder so da?

EDIT:

Sooo, ich habe folgendes geändert:

- Gast hat nur noch 2 vCPUs, ihr dediziert den Kern 0 und 1 zugewiesen und den Share für die CPU auf "high" gestellt
- 4 GB FB-Dimms (4x 1 GB) testweise rausgeschmissen, 6 GB Memory fest der Gast-VM zugewiesen

Der Benchmark lief dann noch einmal durch und verändert hat sich leider gar nichts. Es sind jetzt 538/1011 Punkte im Unixbench.

Ich habe noch ein paar Screenshots von den Einstellungen gemacht, vielleicht hilft das.

 

[fdsonne]

Mit vier Cores hast du 532/1374 Punkte und mit zwei Cores in einem Socket 538/1011?
Da muss irgendwas faul sein...

Vor allem, mach mal die Reservierungseinstellungen ganz raus...
Wie ich in deinem letzten Bild erkenne, hast du dort Reservierungen und Limits gesetzt...

 

[icebeer]

Mit vier Cores hast du 532/1374 Punkte und mit zwei Cores in einem Socket 538/1011?

Ganz genau. Nativ sind es für einen Core knapp über 1.000 Punkte und mit 4 Kernen rund 3.000 Punkte.

Ich habe jetzt mal die fixen Reservierungen rausgenommen und der VM die CPU-Kerne 2&3 zugewiesen. Ich hatte irgendwo gelesen, dass der Kern 0 auch von ESXi viel für Interrupts genutzt wird. Leider hat sich nichts verändert. Ich bin jetzt bei 539 / 1013 Punkten im UnixBench für zwei virtuelle Kerne. Immer noch also 50% langsamer als nativ.

Noch eine Idee?

 

[Loopman]

Noch eine Idee?

Die Reservierung komplett raus? Also auch kein 0-1/2-3, sondern den String leer lassen.

 

[icebeer]

Dann sind wir wieder beim Resultat aus dem Eingangspost.