ESXi auf HP DL380 G5 - Performance ist unterirdisch

[joerady]

Hi und Hallo,
nachdem ich hier erst mal eine Weile mitgelesen hab und mir keine Erwähnung meines Problems aufgefallen ist, will ich doch mal um Hülfää rufen:

ich hab ´ne HP DL380 G5 mit 6 GB RAM und ganz nett platten (original von HP, keine Fremdhardware).
Darauf laufen für Software-test einige VM: Suse 11, Ubuntu 804, Fedora 10, Win 2003.
jeweils mit VMware Tools

Wenn die Serverapplikation angesprochen wird, dauert es u.u. bis zu 40 Sekunden für die erste Rückmeldung (J2EE auf Jboss). das gleiche auf einer standalone-Maschine (HP DL310 G3 mit 1 GB RAM) dauert 0,5 Sekunden.
Ich hab´s schon auf allen o.a. OS´s versucht die Ergebnisse sind ungefähr gleich.
die ESXi läuft seit 8 monaten wg. Zeitmangel mit der beschriebenen angezogenen HAndbremse, aber jetzt soll die teure Hardware auch mal was bringen.

Was, bitteschön mache ich falsch?

[kastlr]

Hallo,

auf so eine Frage kann es überhaupt nur dann eine Antwort geben, wenn du mit deinen Informationen nicht so sparsam umgehst.

Wie viele Kerne mit welcher Taktfrequenz hat dein ESX Server?
Wie viele VM's laufen auf deinem ESX Server parallel?
Welche Ausstattung haben diese VM's (Anzahl UP VM's, Anzahl VM's mit 2 vCPU's, Anzahl VM'S mit 4 vCPU's, zugewiesener Arbeitsspeicher je VM)?
Werden Resourcegruppen, Shares und Reservierungen/Limits verwendet?

Wie prüfst du denn das Antwortverhalten deiner Serverapplikation, lokal oder remote?
Denn es könnte dann auch noch an der Konfiguration deiner Netzwerkkarten, der virtuellen Switche oder den verwendetenen virtuellen NICs liegen.

Und was genau meinst du mit einer Antwortzeit von 40 sec für die erste Rückmeldung, ist die Antwortzeit danach wieder normal?

Mir sagt J2EE und Jboss leider gar nichts, daher kann ich dazu auch nichts sagen.
Allerdings gibt es von VMware einige Performance Studies für Datenbanken, WebServer, vielleicht helfen die dir ja weiter.

Bin gespannt wie's weiter geht.

Gruß
Ralf

[Saturnous]

Ja und besonders da es Netzwerk ist ... welche NICs, wie configt, welche ESX Build, welche PLATTEN (die ORIGINAL SATA PLATTEN SIND LAHMER ALS GEFAKTE SAS).

Am besten zu ziehst das Supportlog und packst es auf nen Filehoster (bitte International), ich schau mal drüber.

Meine gröbstleberwurstigsten Vermutungen :

- IRQ Sharing
- Teaming ohne Beaconprobing + Ostsibirische Wurfverkablung CAT-0
- Switch verhaut die ARP Tables (OSPF vergessen auszuschalten)

[Tschoergez]

Wie viele Kerne mit welcher Taktfrequenz hat dein ESX Server?
Wie viele VM's laufen auf deinem ESX Server parallel?
Welche Ausstattung haben diese VM's (Anzahl UP VM's, Anzahl VM's mit 2 vCPU's, Anzahl VM'S mit 4 vCPU's, zugewiesener Arbeitsspeicher je VM)?

Das wären dann meine gröbstmettwurstigen Vermutungen (:grin:):
- Viele VMs mit vielen vCPUs,
- ein Dualcore-Prozessor im Server
- den VMs soviel RAM eingebaut, dass ordentlich geswappt werden muss
- falscher Kernel im Gast


Bin gespannt... (wir könnten das mal zu einer Sticky-Post-Liste ala "was zuerst überprüfen bei Performance-Problemen zusammenfassen...)

Viele Grüße,
Jörg

[joerady]

Erstmal vielen Dank für das Antworten.
mehr Infos?
aber gerne:

Hardware:
Xeon E5405 2 Ghz 4 Kerne

2 NICs, auf unterschiedliche subnetze gestellt (192.168.128.x, 192.168.129.x)

ESX 3i 3.5.0 110271

11 VM davon 7 aktiv
2x 1 vCPU
4x 2 vCPU
1x 4 vCPU
Memory allocation zwischen 768 und 1500 MB

aggregated CPU usage wird nicht über 1,5 Ghz angezeigt
aggregated Ram usage ist 2.6 von 5 GB

das sollte die Kiste doch nicht überlasten?
die meiste Zeit idlen die VMs vor sich hin.

zu den Antwortzeiten: die sind lokal auf der Konsole genauso schlimm wie übers Netz
die 40 Sekunden sind ein Beispiel, je nach interplanetarer konstellation, kaffesatz-dichte oder sonstwas kanns auch mal auf 10 sekunden sinken oder auf 120 steigen...

JBoss ist ein Java-basierter Application Server (das was man landläufig unter middleware versteht). der verlangt für den Start einen ordentlichen Schub CPU und mindestens 512 MB RAM, danach, wenn er seinen normalen Aufgaben nachgeht ist er ziemlich genügsam.

wie ziehe ich denn ein Supportlog?

Irgendwie scheint sich für mich grade meine kleine wissenslücke zu einem mariannengraben (groß und tief) auszuweiten...
meine bisherige Anmutung von VMware ESXi war:

- erstelle ein paar VM lokal
- konvertiere sie zum ESXi Server
- gib Ihnen eine Obergrenze vCPU (1,2,4 je nach erwarteter Last)
- gib ihnen ein Obergranze RAM

dann wird der Server das ganze schon dynamisch nach Anforderung verteilen, d.h. nicht genutzte Ressourcen freigeben und bei Bedarf anderen VMs zuteilen.

ist da was falsch dran?

vielen Dank für die Erleuchtungen...

[PeterDA]

Hi,
also ein Problem haben wir doch da schon:

2x 1 vCPU
4x 2 vCPU
1x 4 vCPU

Ich Tippe mal das die 4vCPU Maschine die ist die so langsam ist. Kurze Frgae wie soll das auch gehen das eine Maschine alle 4 Kerne nutzt wenn du nur 4 Kerne in deiner Kiste hast. Ich will hier jetzt das Thema mit den vCPUs nicht noch mal auf Rollen, das haben andere hier shcon super erklärt. Einfach mal die Suchfunktion benutzen.

Was du uns noch nicht gesagt hast ist wie viel RAM deine DL380 hat und was für Platten bzw. wie viele, da könnte es auch noch Probleme geben.

Gruß Peter

[kastlr]

Hallo,

zumindest scheint es sich nicht um ein Netzwerkproblem zu handeln, da das beobachtete Verhalten sowohl lokal als auch übers Netzwerk auftritt.

Aber du hast 4 pCPU's, auf denen du 14 vCPU betreibst, das ist ein Verhältnis von 1 zu 3.5 (CPU overcommitment).
Da der Kernel selber auch noch einige CPU Resourcen benötigt, kannst du für deinen ESXi Server von einem CPU Overcommitment von 1 zu 4 ausgehen.

Lies dir doch mal folgende Dokumente durch, welche die Vorgehensweise des Schedulers bei Verwendung von SMP detailliert beschreiben.
http://communities.vmware.com/docs/DOC-5501.pdf
http://communities.vmware.com/docs/DOC-4960.pdf

Du könntest versuchen, das Problem mit CPU Reservierungen zu lösen.
Dein System verfügt über 8000 MHz verfügbarer CPU Resourcen, weise der betroffenen VM doch mal 4000 MHz CPU Ressourcen per Reservierung zu.
Bedenke jedoch, das dies durchaus Auswirkungen auf deine anderen VM's haben wird.
Schließlich steht dann den verbleibenden 6 VM's nur noch 4000MHz zur Verfügung, vergleichbar 2 CPU Kernen.

Am meisten Erfolg verspricht allerdings der Vorschlag, deiner 4vCPU VM zwei Kerne wegzunehmen, damit der Kernel Scheduler die vorhandenen Resourcen besser nutzen kann.
Allerdings kann ich nicht beurteilen, ob deine Middleware diese Änderung automatisch erkennt oder die die Konfiguration mit geeigneten Tools manuell anpassen mußt.

Viel Erfolg
Ralf

[James]

er hat 4 corse
eine vm, die alleine schon 4 cores verwendet

das kann garnicht gescheit laufen

gruss
James

[joerady]

Nochmals vielen Dank,
ich habe jetzt alle VM auf 1 vCPU gesetzt und die Performance ist wie Tag zu Nacht!
das kommt davon wenn man nur einen teil von rtfm beherzigt...
beim groblesen der doku war hier der eindruck erschienen, daß wenn ich mehrere VCPU einer VM zuweise, der ESX mit dem absoluten Minimum auskommt, und dann bei Bedarf eben bis zu 4 Cores auf den Task loslässt.
Daß ich mit SMP bei diesen Machinen eher behindere war mir nicht klar...

gruss, Joe
--

[Tschoergez]

nicht vergessen, in der VM den HAL zu tauschen (bzw. evtl. den Linux-kernel) auf einen 1-CPU-HAL
-> Suchfunktion

Dann sollte es nochmal besser laufen

Viele Grüße,
Jörg