Performance "Problem" mit XP und ESXi 5.1.0

[jauer]

Hallo zusammen,

wir testen gerade den aktuellen ESX auf einem HP Proliant 380 G8.
Leider stellen wir fest, dass ein WinXP gegenüber einem Win7(32bit) mit identischer Hardware beim ablaufen eines Skripts deutlich unterlegen ist.
Die XP VM benötigt bis das Skript durchgelaufen ist ca 1:40min Win7 ca 50sek.
Hat jemand eine Idee wie diese immense Differenz zustande kommen kann?
Die VMs sind "frisch" installiert, also nicht konvertiert.
Sonst ist auch alles weitgehend standard.

Danke für Vorschläge und Tipps schon im Vorraus.

Grüße,
jauer

[Dayworker]

Was heißt bei dir identischer vHW, vCPU-Anzahl und vDISK-Typ?
Was hast du da gescriptet, Netz- oder Laufwerkskram?

[jauer]

Genau selbe CPU Anzahl und Disk.
Das Skript komprimiert im Prinzipo Java Code, der sich auf der lokalen HDD befindet.
Im Netzwerk oder so passiert nichts.

Es ist also schon ungewöhnlich, dass XP wesentlich langsamer ist als Win7, oder?

[UrsDerBär]

Wenn das Script ne Menge kram auf die Festplatte schreibt und liest, kann es gut sein, dass das Alignment der Festplatte einen Strich durch die Rechnung macht, auch wenn mir die Differenz doch etwas hoch erscheint und komprimieren normal ein CPU-Problem ist.

Um das zu umgehen: Festplatte vor installation XP zum Beispiel in eine Win7 VM hängen, formatieren und anschliessend darauf XP installieren ohn erneut zu formatieren.

Nachträglich ändern hat hier irgendwo glaub Dayworker ne nett Aleitung geschrieben.

[2-D]

das aligmnent kann man via Diskpart einrichten. Ich habe gute Erfahrung mit mbralign von NetApp gemacht. Siehe:
http://www.sysadmintutorials.com/tutori ... alignment/

[jauer]

Haben mal alles auf eine RAM-Disk gepackt um die HDD komplett auszuschließen.
Leider ist das Ergebnis das selbe.
Gibt es noch einen anderen Punkt an dem man ansetzen könnte. Irgendwelche Settigns an denen man "rumspielen" kann?

[Dayworker]

Neben dem Alignment, in unserem Forum zu finden unter HowTo - Nachträgliches Alignment auf Sektor 2048, können auch die Grössen von vRAM und vCPU eine Rolle spielen. XP ist im Gegensatz zu allen Win-OS ab Vista längst nicht so stark auf Multicore optimiert und viel RAM macht ein OS aufgrund ansteigenden Verwaltungsoverheads meist auch deutlich langsamer. Du schleichst bei deinen Ausführungen zur vHW aber immer um den heißen Brei rum und lieferst uns keine genauen Angaben.
Auf der anderen Seite könnten auch noch die üblichen Verdächtigen von Avira, Comodo, Kaspersky, Avast etc mit reinspielen, die sich gerade bei Thin/Sparse-Disks zusätzlich kontraproduktiv auswirken.

[2-D]

Vielleicht sollte man auch im Hinterkopf behalten, dass hier ein neues (64-bittiges?) Win 7 gegen ein altes XP antritt. Ergibt sich vielleicht ein Benefit schon aus dem OS heraus bei der Aktion?

Sonst gebe ich Dayworker recht, es fehlen spezifische Angaben zu den Maschinen die du vergleichst.

[UrsDerBär]

@2-D: Er schreibt bei beiden es sei 32bit.

Ansonsten: Ich habe es noch nie wirklich erlebt, dass bei 32bit ein neues Windows OS schneller war als XP bzw. je schneller je älter.
Echte-Multicore Anwendungen mal davon ausgenommen, da weiss ich es schlicht nicht.

[2-D]

Ups...jap....überlesen Danke

[jauer]

Die VMs sind jeweils komplett frei von Zusatzsoftware. Sprich OS ganz frisch aufgesetzt und dann nur Eclipse drauf kopiert. Es wurden keine Firewalls oder AVs installiert. In einer Domäne sind beide auch nicht, sodass irgendwelche AD-Richtlinien oder so dazwischen funken könnten.

Bei der Hardware beide haben jeweils 2CPUs(2cores1sockel) und 4GB Ram. Die HDDs sind jeweils 100GB groß. Haben auch schon verschiedene Schnittstellen ausprobiert, macht aber kaum einen Unterschied.
Die restliche HW ist default.
Der Host hat zwei Xeon E5-2450 (2,1GHz) & 88GB Ram
Welche Informationen könnten noch relevant sein?

Das Skript selber benötigt allerdings nur eine CPU.

Werde das mit dem Alignment mal noch versuchen.

[jauer]

Hab das Alignment (das falsch war) mit der Anleitung von Daywalker angepasst.
Allerdings hat das nichts geändert...

[UrsDerBär]

Sehr seltsam finde ich. Eine bewusste Bremse als Dankeschön an MS sollte VmWare für XP eigentlich nicht eingebaut haben =)

Ansonsten: Schnittstelle hast ja auch verschiedene versucht. Auch die LSI SAS für XP? Glaube aber eher nicht daran.

Einne nette Bremse unter XP ist noch der Defragmentierer.

Was anderes: CPU-Belastung ist aber nicht dauernd bei 100%?

Dazu evtl. mal die HowTo von VmWare für View/Horizon durchgehen was man so alles für eine VM abschalten sollte/kann.

[jauer]

Der Defragmentierer läuft aber auch nicht ständig.
Die CPU ist im Ruherzustand normal bei ca 1%. Wenn das Skript läuft entsprechend volle Last auf einem Kern.

Wo finde ich diese HowTO?

[UrsDerBär]

Dieses hier ist scheint erinnerungsmässig ziemlich komplett zu sein nach kurzer drübergucken:
http://www.ituda.com/Docs/VMware/Best_P ... Images.pdf

Ansonsten eben bei Vmware direkt schauen.

Für 7: http://www.vmware.com/files/pdf/VMware- ... ws7-EN.pdf

Dieser hier hat sich auch viel Mühe gegeben: http://znil.net/index.php/VMware:VMware ... _Windows_7

Eigentlich der beste Link, habe ich nur nicht auf anhieb wiedergefunden.
Hier wird auch gleich ein Einbremsübeltäter genannt: Search 4.0

[mbreidenbach]

Der Defragmentierer sollte in einer VM NIEMALS laufen.

[Dayworker]

Würde ich mit einem klaren JEIN beantowrten.
Falls die VMDK vom Typ Thick ist, wird ja "nur" das Storage ausgebremst. Anders sieht es dagegen bei Thin- bzw Sparse-VMDKs aus. Die werden beim Defragmentieren wie auch bei einer vollständigen Formatierung im Gast-OS auf die eingetragene, volle Grösse der VMDK aufgeblasen und falls eine SSD als Storage fungiert, ist ein Defragmentierer natürlich ebenfalls kontraproduktiv.

[UrsDerBär]

Klugscheissmodus: Ich finde sehr wohl, dass man seine Golden-Images sauber defragmentieren sollte. Bissel entlasten wird das ein Storage oder der Performance zugte kommen. Gaaaanz genau verglichen hab ichs aber auch noch nicht.

Datenrekonstruktionen die es nie geben sollte und immer wieder gibt sind je nach Fall um ein vielfaches einfacher und zielführender bei Defragmentierten Daten.

Ansonsten wurde der rest von Irix schon gesagt.

[Dayworker]

Urs der war gut. irix hat in diesem Thread noch garnix gepostet.

[UrsDerBär]

@Dayworker: Mea culpa, wollte eigentlichen deinen schreiben

[Dayworker]

Welchen Sinn soll es eigentlich haben, daß du XP mit vollen 4 GB vRAM ausstattest?
Ohne weitere Einstellungen sind nur 2GB nutzbar und selbst wenn du XP über einen boot.ini-Parameter zu 3-3.5GB verhilfst, wird kein Prozess mehr als 2GB RAM zugeteilt bekommen. In meinen Augen hat dein XP einfach zuviel vRAM und wie bereits schon einmal geschrieben, vergrössert viel RAM immer auch den dafür nötigen Verwaltungsoverhead. Da dürfte Win7 wesentlich ergonomischer sein und dazu kommt dann noch, daß Win7 auf Multicore-Systeme optimiert wurde. Deine VM-Einstellung 1 Sockel mit zwei Kernen ist je nach SW nur für dessen Lizenz oder das OS selbst wichtig. M$-Desktop-OS kommen eigentlich nur mit 2 Sockeln zurecht und einige SW wird nach vorhandenen Sockeln lizenziert, es wird damit also billiger. VMware mißt, auch wenn möglichst immer die Ausführung auf demselben Sockel bevorzugt wird, dieser Einstellung aber ansonsten nur wenig Bedeutung bei. Die beiden Kerne deiner VM können also durchaus auch auf dem ersten logischen (Kern 1 von Sockel 1) und dem 32ten logischen Kern (Kern 16 auf Sockel 2) deines Xeon E5-2450 ausgeführt werden.
Im Endeffekt wird eine VM auf einen gerade freien Kern ausgeführt und das kann dann auch schon mal auf einem HT-Kern sein. Je nach Host-Auslastung steigt dadurch die Ausführungszeit weiter an und HT selbst bringt im besten Fall maximal 40% eines physikalisch vorhandenen Kerns.

[~thc]

Ohne weitere Einstellungen sind nur 2GB nutzbar und selbst wenn du XP über einen boot.ini-Parameter zu 3-3.5GB verhilfst, wird kein Prozess mehr als 2GB RAM zugeteilt bekommen.

XP erkennt von den 4 GB rund 3 bis 3,5 GB alleine und nutzt diese auch. Der "/3GB"-Schalter in der boot.ini ermöglicht auch einzelnen, entsprechend kompilierten Applikationen 3 GB RAM zu nutzen:

http://msdn.microsoft.com/en-us/library ... 87508.aspx

[Dayworker]

Nur weil XP immer in Abhängigkeit zur installierten Zusatz-HW zwischen 3-3.5GB sehen kann, der Rest wird vom PCI-Adressbereich, Memory-Mapped-IO etc belegt, ändert das nichts für die Anwendung. Um die 3GB real nutzen zu können, muß, wie auch im M$DN-Eintrag geschrieben, das "Large-Adress-Aware-Flag" gesetzt sein. Das wurde und wird meines Wissens nur von wenigen Anwendungen getätigt. Bei Mozillas Firefox gab es entsprechende Postings.
Wenn die Anwendung mehr RAM zur Ausführung braucht, kommt man um eine 64bit-Anwendung zumindest unter XP unabhängig vom Servicepack nicht herum. Selbst die Ausführung einer 32bit-Anwendung unter einem 64bit-OS erhält maximal 4GB zugewiesen, von denen die meisten Anwendungen trotzdem wieder nur 2GB nutzen werden. Das sind halt die Nachwehen von XP.
Auf der anderen Seite konnte man bei mehr als 4GB installierten RAM - auch an XPSP2 vorbei - diesen RAM durch geeignete SW zum Beispiel als RAM-Disk zu nutzen. Gavotte ist dafür das Suchwort. Bei meinem alten E520 mit 6GB RAM konnte ich dadurch jedenfalls fast 3GB als RAM-Disk nutzen. Ärgerlich daran war nur, daß der Ruhezustand nicht mehr richtig funktionierte und die USV den Rechner während eines Stromausfalls nicht herunterfahren konnte. Die USV bzw XP monierte eine unwillige Anwendung und fragte nach einem Benutzereingriff...

Ausgehend von http://www.geoffchappell.com/notes/windows/license/memory.htm sehen seit Vista auch 32bittige Desktop-Windows sämtlichen installierten RAM und können diesen mit etwas Nachhilfe auch nutzen. Von daher ist Win7 etwas im Vorteil.



Um auf das ursprüngliche Performanceproblem zurückzukommen...
Die Script-Ausführungszeiten dürften je nach genutzten CPU-Kern ziemlich schwanken und ohne manuellen Eingriff sprich setzen einer Affinität, wird man auch keine bessere Mittelung der Ausführungszeit hinbekommen.