Seite 1 von 1

problematische Anwendung, performance Analyse

Verfasst: 11.11.2011, 12:05
von mangold
moin,
eigentlich ist das eine allgemeine Frage, da wir aber noch ESX4 betreiben, schreibe ich das hier rein.

Inzwischen virtualisiere ich seit 2004 (ESX2.0) und wir haben das hier zur IT Strategie gemacht. Ich sage das ist Strategie, weil das unternehmen statt 250 physische Server zu betreiben, nur 30 physische Server benötigt. In den 7 Jahren sind mir nur sehr wenige Anwendungen untergekommen, die merklich schlechter "performten" als auf physischer Hardware. Der Overhead bei Virtualsierung ist inzwischen recht gering, vielleicht sind die heutigen Server auch viel zu leistungsfähig für die Software. Das ist ja wohl auch der Hauptgrund warum wir virtualisieren können.

Wenn etwas virtualisiert nicht laufen wollte, dann lag das meist am Unwillen oder Unfähigkeit sich mit der Materie auseinander zu setzen. Meiner Erfahrung nach, lag das Problem aber fast immer an der Software und nicht an der Virtualisierung selbst.

Nun ist mit wieder eine Software untergekommen (Datawarehouse mit MSI), die nachweislich (muss die Aussage so hinnehmen), die virtualisiert wahrnehmbar schlechter läuft als auf Hardware.

Vor allem bei Webservern, die auf phyische DBs zugreifen habe ich das bemerkt.

Der Verantwortliche weigert sich deswegen zu virtualisieren (Grund: er hat keine Kenntnisse in Virtualisierung), die Bereitschaft zusammen eine Lösung zu finden ist etwas niedrig. Ich möchte von der politischen Problematik abgesehen, nun einen Weg zu finden diese Anwendung zu optimieren, ohne dass ich wirklich Kenntnisse dieser Anwendung habe.

So weit ich das bisher mit VMware Mitteln (im Wesentlichen Perfomance Reiter innerhalb des VCenters) und Task Manager innerhalb der VM ermitteln konnte, nutzt die VM die ihr zugewiesenen Reesourcen nicht aus (vCPUs und Ram), ich schließe deshalb erstmal aus, dass die VM zu klein dimensioniert wurde, oder die physischen Ressourcen nicht ausreichen. Auch der Host selbst zeigt keine Auffälligkeiten und ist bei weitem nicht ausgelastet.

Ich vermute die Probleme in den Netzwerklatenzen. Was ich bisher häufig sehen konnte, ist das Netzwerklatenzen im virtualisierten Netzwerk (Kommunikation über das physische Netzwerk ist notwendig) etwas höher sind. Wenn sich Requests gegen eine DB von 1 ms auf 2 ms verdoppeln, ist das im Einzelnen nicht dramatisch, macht die Anwendung aber 1000 davon, wartet der User zwei Sekunden statt einer.

Welche Ansätze habe ich hier?
- einen dedizierten vSwitch (mit eigener pNic) für diese eine VM?
wenn die Virtualisierungsschicht selbst die Ursache ist, wird dies nicht viel bringen.
- eine pNic direkt an die VM durchreichen (unter Umgehung des virtuellen Netzwerks)? Geht das? Habe ich nie probiert und kann auch auf die Schnelle nichts finden. Könnte das was bringen.

Welche Ansätze habt ihr, wenn Ihr vor solch einem Problem steht?

Verfasst: 14.11.2011, 12:17
von stahly
Hast Du vmxnet3 eingestellt?
Arbeitest Du mit VLANs?

Verfasst: 14.11.2011, 12:45
von mangold
VLANs werden - so weit benötigt - eingesetzt. Diese Anwendung hat aber kein eigenes VLAN, das ist im normalen Server VLAN. Letztendlich laufen aber alle VMS über den Trunk. Die pNics sind auch nicht ausgelastet, die verfügbare Bandbreite scheint auch nicht das Problem zu sein.

Der Wechsel auf VMXNET3 erscheint mir so oder so sinnvoll, dieses System ist noch auf E1000, danke für den Hinweis.

Trial&Error ist natürlich ein probates Mittel zum Optimieren :D eine Analyse wäre mir aber lieber.

Sonst noch irgendwelche Ideen für die Analyse?

Verfasst: 14.11.2011, 14:22
von Nukite2007
von welchen Betriebssystemen sprichst Du denn bei den DB-Servern und welches OS haben die Webserver?

Verfasst: 14.11.2011, 14:40
von mangold
normales Win 2003 mit IIS, die DB Server sind nicht virtualisiert (Sind physische AIX/DB2 Systeme).

Leider sind die Webanwendungen mit MSI absolut proprietär und dazu noch selbst entwickelt. Also keine Möglichkeit von meiner Seite aus DA rein zu gehen.

Verfasst: 14.11.2011, 15:57
von kastlr
Hallo,

da du die Netzwerklatency im Verdacht hast, ist die denn identisch für deine virtualisierten WebServer?
Nicht das beim Einsatz eines physischen WebServer dieser im selben LAN Segment wie der DB Server steht, während dein virtueller Webserver erst mal über mehrere Hop's springen muß, um an den DB Server zu gelangen.

Und dann kannst du ja mal folgenden VMware KB Artikel überprüfen.
The output of esxtop shows dropped receive packets at the virtual switch

Ich würde in so einem Fall mal esxtop Daten sammeln, um einen allgemeinen Überblick über die Aktivitäten zu bekommen.
Alternativ könntest du dir im vCenter mal die Ready Times der VM ansehen, ob die eventuell zu hoch sind.

Ist halt nicht wirklich eindeutig, wo genau das Problem herkommt (oder ob es sich überhaupt um ein solches handelt ;-) )

Viel Spaß,
Ralf

Verfasst: 14.11.2011, 16:17
von mangold
kastlr hat geschrieben:Hallo,

da du die Netzwerklatency im Verdacht hast, ist die denn identisch für deine virtualisierten WebServer?
Nicht das beim Einsatz eines physischen WebServer dieser im selben LAN Segment wie der DB Server steht, während dein virtueller Webserver erst mal über mehrere Hop's springen muß, um an den DB Server zu gelangen.

Und dann kannst du ja mal folgenden VMware KB Artikel überprüfen.
The output of esxtop shows dropped receive packets at the virtual switch

Ich würde in so einem Fall mal esxtop Daten sammeln, um einen allgemeinen Überblick über die Aktivitäten zu bekommen.
Alternativ könntest du dir im vCenter mal die Ready Times der VM ansehen, ob die eventuell zu hoch sind.

Ist halt nicht wirklich eindeutig, wo genau das Problem herkommt (oder ob es sich überhaupt um ein solches handelt ;-) )

Viel Spaß,
Ralf
Das mit den Hops werde ich mal überprüfen, ob da ein Unterschied zustande kommen kann.

Mittlerweile wurden die "Messwerte" von pro-Virtualisierungs-Kollegen aus dem Umfeld der Anwendung gesichtet, das Problem scheint kein wirkliches Problem zu sein, bzw, kein Problem der Virtualisierung. 8)

Dennoch; Unterschiede sind messbar, Optimierungen sind immer gut und Anregungen seitens Außenstehender immer willkommen. Ich will nicht nach dem Motto arbeiten: "mach ich schon immer so, deswegen bleibt das so" und "bei mir ist alles ok, muss dein Problem sein". Das kenne ich von Anderen, meine eigene Arbeit versuche ich dagegen stets kritisch zu betrachten. ;)

Verfasst: 14.11.2011, 16:46
von kastlr
Hallo,

das LAN Design ist dabei schon sehr entscheidend, speziell die Verbindungen der Switche & Router untereinander.
Ich bin zwar mehr im SAN unterwegs, aber dort finden sich die Fehler auch immer häufiger auf den ISL (inter switch link).
Denn es ist halt sehr einfach, an einen Switch ein paar neue Server zu hängen, aber ob der ISL diese zusätzliche Last noch stemmen kann wird dabei oft vergessen.
Und dabei unterscheiden sich LAN und SAN nicht voneinander.

Da sich ja nun aber offenbar die "Cloud" lichtet, sind wir alle mal gespannt wie das hier weitergeht.

Gruß
Ralf