VMs auf verschieden Festplatten verteilen für Performance

[ChristophB]

Hallo Forum,

ich brauch mal Eure Meinung. Ich habe zu meinen 2x 500GB Raid 1, jetzt 2x 146GB 6G Raid 1 Platten hinzugefügt. Darauf Windows 7 Pro 64Bit installiert und die VMs von den 500GB Platten gestartet. Irgendwie laufen die jetzt langsamer. Mein Terminal hat zeitweise 100% CPU Auslastung ?? MIST SWAPPING vergessen aus zumachen!!!! ja ich weiss! kann ich erst heute abend ändern!

Aber trotzdem:
Ich würde gerne um die Performance zu steigern den Terminal und den SQL Server auf die neuen 6G Platten verschieben, weil ich der Meinung bin das VM werden dadurch schneller. Aber beide VM auf verschiedenen Platten sollte auch recht schnell sein.
Wird dann nicht aber die LAN-Verbindung zum Flaschenhals?

Erfahrungen / Meinungen ?

Danke

[Dayworker]

Raid1 sorgt ja generell nicht für Begeisterungsstürme in der Performance, Raid1 ist lediglich Mirroring/Spiegelung und wenn überhaupt, kannst du nur etwas Performance in Leserichtung zugewinnen.
Hast du wenigstens einen richtigen Controller oder nur den im Chipsatz?

In jedem Fall solltest du eine USV davorgeschaltet haben, wenn dir deine Daten lieb sind.

[ChristophB]

Wir setzen das Raid 1 ja auch nur wegen der Ausfallsicherheit ein. Mir ging es mehr um den Perfomance gewinn, wenn ich die VMs auf andere Harddisks auslagere. Das habe dann letzte Woche Windows 7 Pro 64 bit auf die neuen Platten installiert und den SQL und den Terminal hinterher kopiert und bin nicht begeistert ! Egal welche von beiden VMs ich zuletzt starte die Performance ist im Keller. Selbst die kleinsten Prozesse brauchen richtig Leistung! Dementsprechend sit die Performance. Die Buchhaltung im Terminal die auf den SQL zugreift ist grotten langsam!

Ich brauch dringend Hilfe!

Was kann das sein. Ich habe mit dem neuen Windows 7 auch das VMware Server 2.0.2 Update gemacht. Habe die Tools aktualisiert. Und ALLES andere so gelassen.

[Dayworker]

Also erstmal ist W7 als Desktop-OS nicht von VMware als Host-OS freigegeben. Das muß bekanntermaßen nichts heißen, mein XP32 läuft genauso wie vormals auch ein normales W2k, kann aber auch Probleme verursachen. Dazu kommen dann allerdings Probleme mit der UAC und der Erkennung neuerer CPUs seit dem Nehalem. Beide VMserver sind inzwischen EOL und werden nur noch im Rahmen eines bestehenden Supportvertrages bis Ende Juni/Juli 2011 gepflegt.

Auch wenn die VM auf verschiedenen Platten liegen, haut das Raid1 immer voll rein. Alle Raidmitglieder müssen erst die Daten geschrieben und fertig gemeldet haben, dann gehts weiter. Bei vielen kleinen IO-Anforderungen durch einen DB-Server hat das Raid1 einfach einen Performanceengpaß, daher würde sich ein Raid5 weit besser als DB-Unterbau machen.

Alles in allem läßt ich sagen, daß der VMserver2 nicht das Gelbe vom Ei ist. Unter Linux und anscheinend auch unter Windows kämpft man mit einer stetig ansteigenden Host-Auslastung durch den jeweiligen VM-Prozeß "vmware-vmx" (Gast) und das selbst bei im Leerlauf befindlichen Gästen. Diese ansteigende Host-Auslastung habe ich unter VMserver1 noch nie gesehen, sonst wären mir Laufzeiten von 6 Monaten oder länger nicht möglich gewesen. Allerdings kann der VMserver1 überhaupt nichts mit einer UAC anfangen.

[ChristophB]

OK, danke.

vorher lief alles einwandfrei. VM server 2.0.1 auf nem XP64! änderung waren nur W7 und 2.0.2 und neue Festplatten.
Das Problem ist das immer die zu letzt gestartete VM das Problem hat ! RAM ist für alle genug da! swapping ist aus ! Kann die hohe CPU Last durch die neuen Festplatten kommen. Der Terminal als 2. gestartet hat das Problem nicht ! Es sei denn ich starte ihn als letzten. ??? äähhh

P.S. Ich betreu noch 4 andere Systeme W7 Pro 64bit, 3 VM von denen hat keiner das Problem !

[Dayworker]

XP64 = W2k3, daß erklärt doch alles.
Wie im VMserver1-Bereich schon gefragt, wie sind die VMs mit HW ausgestattet?

W7 kann als Desktop-OS sowieso keine Vorteile aus SAS-Platten ziehen oder nur unter einen HW-Raid-Controller ala Dell Perc5i/6i, LSI Megaraid etc.

[ChristophB]

der SQL:
Processors 2 X 4.556 GHz, Memory 1024 MB
der Term:
Processors 2 X 4.556 GHz, Memory 4096 MB

Host --> Signatur + 2x 146 GB SAS

Wenn ich mir die Auslastungen im Performance-Monitor von Windows 7 anschaue, ist die HDD Auslastung gering ! also schließe ich daraus das er nicht großartig in den VMDK arbeitet ! ich vermute es ist die Ansteuerung des RAM. Das LESEN und SCHREIBEN der VM im RAM kostet viel CPU.....

WARUM NUR ?

[Dayworker]

der SQL:
Processors 2 X 4.556 GHz, Memory 1024 MB
der Term:
Processors 2 X 4.556 GHz, Memory 4096 MB

Host --> Signatur + 2x 146 GB SAS

2 X 4.556 GHz ist Blödsinn, dann hätte ich ja mit dem Core_i7-990 volle 41.52 GHz CPU-Geschwindigkeit. Du hast also den VMs 2 v.CPUs gegeben, was in der VT-Welt zumindest im VMware-Desktop-Bereich meist unproduktiv ist. Setz beide VMs mal auf 1 v.CPU zurück und teste erneut. Das die VM mit 4 GB auch ziemlich überdimensioniert ist, brauch ich dir in diesem Zusammenhang wohl auch nicht mehr sagen, ist aber leider so und bevor die nächste Frage dazu kömmt, gibts die Antwort gleich hinterher.
Der VMserver2 kann im Gegensatz zum VMserver1 zwar bis zu 8GB pro VM vergeben, allerdings wird diese VM dadurch unglaublich langsam. Wie auf realer HW wird auch eine VM mit soviel RAM langsamer, da die Verwaltung umfangreicher wird. Nicht umsonst lassen sich bei Server-OS auch diese Bigmem-Pages (4MByte Pagegröße statt der normalen 4KByte) einrichten, damit der Verwaltungsaufwand gesenkt wird.

[ChristophB]

für die 4GHz kann ich nicht ! siehe http://ifile.it/9ispkt6

und die 4GB braucht die Datev Software sonst läßt die sich nicht installieren !
die zuletzt gestartet VM macht das Problem! es ist egal welche vHardware sie hat! Wenn ich nur eine CPU zuweise läuft die bei 100% CPU. Bei vCPU. wenigstens manchmal drunter !

Gibt n Eintrag für die Optimierung des RAM Zugriffs - ausser dem swapping Sachen?

[Dayworker]

ür die 4GHz kann ich nicht !

Ja ich weiß, macht aber trotzdem keinen Sinn...

und die 4GB braucht die Datev Software sonst läßt die sich nicht installieren !
die zuletzt gestartet VM macht das Problem! es ist egal welche vHardware sie hat! Wenn ich nur eine CPU zuweise läuft die bei 100% CPU. Bei vCPU. wenigstens manchmal drunter !

Welche Prozesse in der VM ziehen denn die Leistung?

Gibt n Eintrag für die Optimierung des RAM Zugriffs - ausser dem swapping Sachen?

Mit den swapping-Einträgen verringerst du im Endeffekt nur sämtlichen unnötigen IO-Traffic und die VMs haben dann etwas mehr Leistung zur Verfügung. Sind die Platten auf Preallocated umgestellt und Snapshots deaktiviert oder zumindest nicht aktiv?

Kannst du von beiden VMs bitte mal das ungekürzte, aktuellste "vmware.log" auf einen Freehoster ohne Flash oder Wartezeiten verlinken, vielleicht findet sich dann noch etwas.

[ChristophB]

Terminal log ist voll von : Feb 21 09:44:47.639: vcpu-1| Not caching pages 2693274 through 2693337 because of write on page 2693288 on write.
http://ifile.it/kzhlms7

und im SQL: Feb 19 17:04:51.390: vcpu-0| pciBridge6:4: ISA/VGA decoding enabled (ctrl 0004)
http://ifile.it/li68xbm

[Dayworker]

Terminal log ist voll von : Feb 21 09:44:47.639: vcpu-1| Not caching pages 2693274 through 2693337 because of write on page 2693288 on write.
http://ifile.it/kzhlms7

Ich seh schon, daß kommt von der 2v.CPU-Einstellung. Du bist zwar der Meinung der VM eine Dualcore-CPU gegeben zu haben, dem ist aber nicht so. Lies dir dazu mal mein Posting im Thread Wichtig: Server2,HW-Upgrade,VI-Client,supp.Host-OS,Permission,Optimum durch. In Kurzform bedeuten 2 v.CPUs immer zwei Singlecore-CPU in einer 2Sockel-Config und die Koherenz zwischen beiden CPUs wird immer in SW abgebildet. Wenn die VM also unter Volllast steht, dauert dieser Abgleich zu lange...
Die v.Disk ist günstigerweise vom Typ "twoGbMaxExtentFlat" und hat keine Snapshots.

und im SQL: Feb 19 17:04:51.390: vcpu-0| pciBridge6:4: ISA/VGA decoding enabled (ctrl 0004)
http://ifile.it/li68xbm

Die VGA-Meldungen sind nicht relavant, aber folgendes ist es:

Feb 19 19:10:40.691: vcpu-1| DISKLIB-LIB : numIOs = 50000 numMergedIOs = 2046 numSplitIOs = 403
Feb 19 19:31:56.866: vmx| DISKLIB-LIB : numIOs = 100000 numMergedIOs = 7071 numSplitIOs = 1398
Feb 19 19:51:06.304: vcpu-1| DISKLIB-LIB : numIOs = 150000 numMergedIOs = 13155 numSplitIOs = 2739
Feb 19 20:10:41.384: vcpu-0| DISKLIB-LIB : numIOs = 200000 numMergedIOs = 17464 numSplitIOs = 4646
Feb 19 20:29:57.089: vmx| DISKLIB-LIB : numIOs = 250000 numMergedIOs = 22249 numSplitIOs = 7667
Feb 19 20:49:44.223: vcpu-0| DISKLIB-LIB : numIOs = 300000 numMergedIOs = 24395 numSplitIOs = 8239
Feb 19 21:08:25.155: vcpu-1| DISKLIB-LIB : numIOs = 350000 numMergedIOs = 25620 numSplitIOs = 8532
Feb 19 21:26:45.952: vcpu-1| DISKLIB-LIB : numIOs = 400000 numMergedIOs = 32402 numSplitIOs = 9709
Feb 19 21:46:06.045: vcpu-0| DISKLIB-LIB : numIOs = 450000 numMergedIOs = 35210 numSplitIOs = 10073
Feb 19 22:05:41.355: vmx| DISKLIB-LIB : numIOs = 500000 numMergedIOs = 38534 numSplitIOs = 10448
Feb 19 22:24:48.150: vmx| DISKLIB-LIB : numIOs = 550000 numMergedIOs = 43903 numSplitIOs = 11730
Feb 20 00:02:23.838: vcpu-0| DISKLIB-LIB : numIOs = 600000 numMergedIOs = 48149 numSplitIOs = 12098
Feb 20 04:36:43.510: vmx| DISKLIB-LIB : numIOs = 650000 numMergedIOs = 50856 numSplitIOs = 12280

Diese v.Disk ist defragmentiert und sowas passiert bei Sparse-Disks (mitwachsenden v.Disks) häufiger und besonders wenn dann auch noch ein Snapshot zum Einsatz kommt:

Feb 19 17:17:06.387: vmx| DISKLIB-LINK : Opened 'c:\vm\XP_pro\Windows XP Professional-000003-cl2.vmdk' (0xe): twoGbMaxExtentSparse, 41943040 sectors / 20 GB.

Daher solltest du zuerst mal die VMDK shrinken, den Ablauf hat Ulli hier im Forum schon beschrieben, und dann nicht nur über die Konsolidierung des Snapshots nachdenken sondern diesen komplett aufgeben. Ohne regelmäßiges manuelles Shrinken (M$ Virtualisierungslösung macht das immer automatisch) verweigern sämtliche VMware-Produkte früher oder später dann entweder nur den VM-Start oder du riskierst den kompletten Verlust aller Daten in der VM! Da ein Snapshot kein Backup ist, verursacht dieser spätestens beim Vergrößern der v.Disk größere Bauchschmerzen. Über die GUI ist in diesem Fall eine Vergrößerung nicht mehr möglich und müßte daher umständlich und fehlerträchtig von Hand gemacht werden.

[ChristophB]

Wir hatten die VMs mit Ihren RAM Zuteilungen aus xp64, so in Windows 7 wieder gestartet!
Windows 7 braucht das dreifache an RAM. Sodass immer die zuletzt gestartete VM sich mit W7 um den Ram gestritten oder hat selbst nicht genug abbekommen hat. Nach dem wir den RAM des Terminal halbiert hatten und dem SBS auch noch 1/2 Gig entzogen hatten. Lief alles wieder!
SO und zum Thema 1 oder 2 vCPU, der SQL läuft wirklich gemessen schneller mit nur einer vCPU ! "Ja" hattest recht Der Terminal hingegen" läuft mit 2 vCPU gemessen schneller!
Ich denke hat einfach mal mit der Architektur zutun. Ein Server ist ja ehr dafür ausgelegt mit 2 CPU zu arbeiten, ein XP ja nicht.

OK Danke Dayworker!

Nachtrag: (müßte man eigentlich mit in einen Standard-Antworten Thread nehmen! )

!!!der VMware Server kann mit der Workstation gemachte Snapshoots nicht löschen!!! wenn ich die VM in der Workstation öffne, klappts !!!

[Dayworker]

!!!der VMware Server kann mit der Workstation gemachte Snapshoots nicht löschen!!! wenn ich die VM in der Workstation öffne, klappts !!!

Das ist nichts neues für mich. Der VMserver2.02 hat zwar fast dieselbe Codebasis wie die WS5.5.2, aber seitdem hat sich spätestens in der WS7 einiges verändert und die VMserver1/2 können im Gegensatz zu Player oder WS nur einen Snapshot vorhalten. Snapshotketten wie bei Player, WS, Fusion oder auch ESX(i) sind über die VMserver-GUI nicht möglich und müssen manuell angelegt werden.