Win 32 Bit unter WS 6.5.5 startet sehr langsam

[rprengel]

Hallo,

eine Win97 32 Bit Maschine braucht hier fast 5 Minuten um zu starten.
Das System hat 3072 MB Ram. Der Host ist ein Core 7 mit 8 GB Ram auf Win 7 64 Bit.
Die einzige Besonderheit:
Das System hat eine virtuelle 500 GB Festplatte in 2 GB files .
Alle anderen Systeme starten sehr schnell, haben aber max 30 GB Festplatten.
Hat jemand Tips woran ich ggf. drehen kann? Ram ist fest zugewiesen.

Gruß

[continuum]

lad das vmware.log bei ifile.it hoch - dann kann ich dir sagen wo es hapert

[rprengel]

lad das vmware.log bei ifile.it hoch - dann kann ich dir sagen wo es hapert

http://ifile.it/lvh0sig/vmware.log
Nachtrag:
im laufenden Betrieb ist die Maschine einwandfrei aber gestern hat sie beim herunterfahren noch einen Crash hingelegt.

Gruß und Dank

[continuum]

Hmmm
wieso du tausend von solchen Eintraegen hast
Not caching pages 9056830 through 9056893 because of write on page 9056843 on write.

verstehe ich nicht - muss ich nachgucken.
jmattson hat mal dazu was geschrieben

[rprengel]

Hmmm
wieso du tausend von solchen Eintraegen hast
Not caching pages 9056830 through 9056893 because of write on page 9056843 on write.

verstehe ich nicht - muss ich nachgucken.
jmattson hat mal dazu was geschrieben

Das wäre ein Ansatz
http://vmware-forum.de/viewtopic.php?t=19305
Ich teste das nachher aus.

Gruß

[Dayworker]

Mar 29 20:01:50.442: vcpu-0| Switching from cacheEntry to writeEntry on page 120898762
Mar 29 20:01:50.442: vcpu-0| Switching from cacheEntry to writeEntry on page 120898763
Mar 29 20:01:50.442: vcpu-0| Switching from cacheEntry to writeEntry on page 120898764
Mar 29 20:01:50.442: vcpu-0| Switching from cacheEntry to writeEntry on page 120898765
Mar 29 20:01:50.442: vcpu-0| Switching from cacheEntry to writeEntry on page 120898766
Mar 29 20:01:50.442: vcpu-0| Switching from cacheEntry to writeEntry on page 120898767
Mar 29 20:01:50.442: vcpu-0| Switching from cacheEntry to writeEntry on page 120898768
Mar 29 20:01:50.442: vcpu-0| Switching from cacheEntry to writeEntry on page 120898769
Mar 29 20:01:50.443: vcpu-0| Switching from cacheEntry to writeEntry on page 120898770
Mar 29 20:01:50.443: vcpu-0| Switching from cacheEntry to writeEntry on page 120898771
Mar 29 20:01:50.443: vcpu-0| Switching from cacheEntry to writeEntry on page 120898772
Mar 29 20:01:50.443: vcpu-0| Switching from cacheEntry to writeEntry on page 120898773

Solche Einträge passieren immer dann, wenn VMware Arbeitsspeicher auslagern muß. Daher beginnen die Einträge auch mit vcpu-0. Lösen läßt sich das recht einfach, indem man eine Reservierung des RAMs für VMware in den erweiterten Host-Einstellungen einstellt. Im Prinzip fehlen hier Einträge in der "config.ini" wie:

Mar 21 22:38:03: vmx| DICT prefvmx.allVMMemoryLimit = 2700
Mar 21 22:38:03: vmx| DICT prefvmx.minVmMemPct = 100
Mar 21 22:38:03: vmx| DICT prefvmx.useRecommendedLockedMemSize = TRUE

Mar 29 19:46:34.307: vmx| DISKLIB-LINK : Opened 'D:\daten\vmware\rprengel\privat_win_7_32_media\Windows 7.vmdk' (0xa): twoGbMaxExtentSparse, 1174405120 sectors / 560 GB.
Mar 29 19:46:34.322: vmx| DISKLIB-LIB : Opened "D:\daten\vmware\rprengel\privat_win_7_32_media\Windows 7.vmdk" (flags 0xa).

Sowas würde ich mir sparen. Die Chancen bei einer v.Disk von 560GB Größe im Sparse-Diskformat einen zusammenhängenden Speicherbereich zu erwischen, dürfte selbst bei halbvollen Terabyte-Drives gegen Null gehen und dann sind folgende Einträge die logische Konsequenz:

Mar 29 20:05:54.410: vmx| DISKLIB-LIB : numIOs = 50000 numMergedIOs = 5600 numSplitIOs = 615
...
Mar 29 20:39:36.411: vmx| DISKLIB-LIB : numIOs = 300000 numMergedIOs = 7913 numSplitIOs = 1055
Mar 29 20:40:11.585: vmx| DISKLIB-LIB : numIOs = 350000 numMergedIOs = 7913 numSplitIOs = 1055

Da heißt es jetzt zu beobachten und die VM regelmäßig zu shrinken. Ulli hat vielleicht noch Info's, ab wann die WS den Start bei stark fragmentierten v.Disks verweigert. Da sich hier aber nur die Anzahl der "numIOs" bei gleichbleibenden "numMergedIOs" und "numSplitIOs" erhöht hat, gehe ich von reinen Lesezugriffen aus und die sind unkritisch. Das ändert sich jedoch, wenn Schreibzugriffe innerhalb der VM gemacht werden. Dazu reicht es auch, die v.Disk innerhalb der VM zu defragmentieren oder vollständig zu formatieren, dann explodieren die Werte für "numMergedIOs" und "numSplitIOs" förmlich.

Mar 30 03:33:45.914: vmx| DISKLIB-LIB : numIOs = 2450000 numMergedIOs = 23387 numSplitIOs = 4981
Mar 30 03:34:55.900: vmx| DISKLIB-LIB : numIOs = 2500000 numMergedIOs = 23545 numSplitIOs = 4992
Mar 30 03:36:01.783: vmx| DISKLIB-LIB : numIOs = 2550000 numMergedIOs = 23699 numSplitIOs = 5001
...
Mar 30 04:54:34.528: vmx| DISKLIB-LIB : numIOs = 4550000 numMergedIOs = 27808 numSplitIOs = 6261

Die Werte für "numIOs", "numMergedIOs" und "numSplitIOs" erhöhen sich bei dir ständig und deuten eine stärker voranschreitende Fragmentierung an.
Das erklärt allerdings nicht den Absturz am Ende des Logs


@Ulli
Hat die WS6.5.X eigentlich unter W7/W2k8-R2 auch dasselbe Problem, wenn VMs oder Programme mehr als 30% des Arbeitsspeichers enbloc anfordern oder ist das nur eine "Spezialität" der WS7.X bzw des SP1

[continuum]

@ dayworker

bei den Faellen die ich gesehen habe scheint es an 2008 R2 UND Workstation zu liegen.

Mit WS 7.1.3 konnten wir maximal 30 % des RAMs nach meinen tweaks nutzen - vorher maximal 20%

Unter WS 6.5 lief das besser - aber die Leute wollten Win7 und 2008 R2 VMs laufen lassen - deswegen haben die nach VirtualBOX gewechselt - da war dann locker 80% und mehr nutzbar

[Dayworker]

Okay, also liegt es an der WS7.13 UND W2k8-R2.
Hat sich daran etwas in der neuen 7.14 geändert oder deutet zumindest etwas darauf hin?

[continuum]

Noch habe ich die neue Version unter 2008 R2 noch nicht getestet ... bald weiss ich mehr

[rprengel]

Mar 29 20:01:50.442: vcpu-0| Switching from cacheEntry to writeEntry on page 120898762
Mar 29 20:01:50.442: vcpu-0| Switching from cacheEntry to writeEntry on page 120898763
Mar 29 20:01:50.442: vcpu-0| Switching from cacheEntry to writeEntry on page 120898764
Mar 29 20:01:50.442: vcpu-0| Switching from cacheEntry to writeEntry on page 120898765
Mar 29 20:01:50.442: vcpu-0| Switching from cacheEntry to writeEntry on page 120898766
Mar 29 20:01:50.442: vcpu-0| Switching from cacheEntry to writeEntry on page 120898767
Mar 29 20:01:50.442: vcpu-0| Switching from cacheEntry to writeEntry on page 120898768
Mar 29 20:01:50.442: vcpu-0| Switching from cacheEntry to writeEntry on page 120898769
Mar 29 20:01:50.443: vcpu-0| Switching from cacheEntry to writeEntry on page 120898770
Mar 29 20:01:50.443: vcpu-0| Switching from cacheEntry to writeEntry on page 120898771
Mar 29 20:01:50.443: vcpu-0| Switching from cacheEntry to writeEntry on page 120898772
Mar 29 20:01:50.443: vcpu-0| Switching from cacheEntry to writeEntry on page 120898773

Solche Einträge passieren immer dann, wenn VMware Arbeitsspeicher auslagern muß. Daher beginnen die Einträge auch mit vcpu-0. Lösen läßt sich das recht einfach, indem man eine Reservierung des RAMs für VMware in den erweiterten Host-Einstellungen einstellt. Im Prinzip fehlen hier Einträge in der "config.ini" wie:

Mar 21 22:38:03: vmx| DICT prefvmx.allVMMemoryLimit = 2700
Mar 21 22:38:03: vmx| DICT prefvmx.minVmMemPct = 100
Mar 21 22:38:03: vmx| DICT prefvmx.useRecommendedLockedMemSize = TRUE

Mar 29 19:46:34.307: vmx| DISKLIB-LINK : Opened 'D:\daten\vmware\rprengel\privat_win_7_32_media\Windows 7.vmdk' (0xa): twoGbMaxExtentSparse, 1174405120 sectors / 560 GB.
Mar 29 19:46:34.322: vmx| DISKLIB-LIB : Opened "D:\daten\vmware\rprengel\privat_win_7_32_media\Windows 7.vmdk" (flags 0xa).

Sowas würde ich mir sparen. Die Chancen bei einer v.Disk von 560GB Größe im Sparse-Diskformat einen zusammenhängenden Speicherbereich zu erwischen, dürfte selbst bei halbvollen Terabyte-Drives gegen Null gehen und dann sind folgende Einträge die logische Konsequenz:

Mar 29 20:05:54.410: vmx| DISKLIB-LIB : numIOs = 50000 numMergedIOs = 5600 numSplitIOs = 615
...
Mar 29 20:39:36.411: vmx| DISKLIB-LIB : numIOs = 300000 numMergedIOs = 7913 numSplitIOs = 1055
Mar 29 20:40:11.585: vmx| DISKLIB-LIB : numIOs = 350000 numMergedIOs = 7913 numSplitIOs = 1055

Da heißt es jetzt zu beobachten und die VM regelmäßig zu shrinken. Ulli hat vielleicht noch Info's, ab wann die WS den Start bei stark fragmentierten v.Disks verweigert. Da sich hier aber nur die Anzahl der "numIOs" bei gleichbleibenden "numMergedIOs" und "numSplitIOs" erhöht hat, gehe ich von reinen Lesezugriffen aus und die sind unkritisch. Das ändert sich jedoch, wenn Schreibzugriffe innerhalb der VM gemacht werden. Dazu reicht es auch, die v.Disk innerhalb der VM zu defragmentieren oder vollständig zu formatieren, dann explodieren die Werte für "numMergedIOs" und "numSplitIOs" förmlich.

Mar 30 03:33:45.914: vmx| DISKLIB-LIB : numIOs = 2450000 numMergedIOs = 23387 numSplitIOs = 4981
Mar 30 03:34:55.900: vmx| DISKLIB-LIB : numIOs = 2500000 numMergedIOs = 23545 numSplitIOs = 4992
Mar 30 03:36:01.783: vmx| DISKLIB-LIB : numIOs = 2550000 numMergedIOs = 23699 numSplitIOs = 5001
...
Mar 30 04:54:34.528: vmx| DISKLIB-LIB : numIOs = 4550000 numMergedIOs = 27808 numSplitIOs = 6261

Die Werte für "numIOs", "numMergedIOs" und "numSplitIOs" erhöhen sich bei dir ständig und deuten eine stärker voranschreitende Fragmentierung an.
Das erklärt allerdings nicht den Absturz am Ende des Logs


@Ulli
Hat die WS6.5.X eigentlich unter W7/W2k8-R2 auch dasselbe Problem, wenn VMs oder Programme mehr als 30% des Arbeitsspeichers enbloc anfordern oder ist das nur eine "Spezialität" der WS7.X bzw des SP1

Ok,

endlich mal richtig abgeräumt.
Das System hat sich jetzt eh zerlegt. Ich ziehe die Daten raus und setzte das System neu auf.
Würde ich auf der sicheren Seite sein wenn ich 2 GB Files allocated wählen würde. Ich möchte die Dateien nicht grösser werden lassen um das System sicher über das Netzwerk sichern zu können. Zur Not halt auch per FTP/ NFS wenn nichts mehr geht und da ist bei 2 GB Schluss.

Gruß

[Dayworker]

Ok,

endlich mal richtig abgeräumt.
Das System hat sich jetzt eh zerlegt. Ich ziehe die Daten raus und setzte das System neu auf.
Würde ich auf der sicheren Seite sein wenn ich 2 GB Files allocated wählen würde. Ich möchte die Dateien nicht grösser werden lassen um das System sicher über das Netzwerk sichern zu können. Zur Not halt auch per FTP/ NFS wenn nichts mehr geht und da ist bei 2 GB Schluss.

Gruß

Also ich bevorzuge immer Preallocated-Files, daß erspart jede Menge Ärger. Spätestens zum Shrinken, daß immer in zwei Stufen abläuft, werden im ersten Schritt die sogenannten Whipper-Files innerhalb der VM geschrieben. Dabei werden alle freien Bereiche und dazu zählen auch die als gelöscht markierte Sektoren (Stichwort Papierkorb), ausgenullt und dann im zweiten Schritt aus der v.Disk entfernt. Da aber jedes Dateisystem früher oder später fragmentiert, verteilen sich sämtliche VM-Daten über deren v.Disk und somit müssen die Whipper-Files auch über alle freien Bereiche der v.Disk geschrieben werden. In deinem Fall mußt du also mindestens noch den Platz frei haben, damit die v.Disk auf ihre voll Größe von 560GByte PLUS 2 GByte anwachsen kann.

Ob man die v.Disk dann noch in 2GByte-Häppchen aufteilt, bleibt jedem selbst überlassen. Es sind mir dadurch keine Performanceverluste bekannt geworden und ich mache daher in all meinen VMs davon reichlich Gebrauch. Eher vereinfacht man sich sogar noch die Sicherung. Die Häppchen von 2GByte kann man zur Not noch über mehrere DVDs aufteilen. Bei enbloc-Größen über 25GByte wird es dann schon schwerer, da selbst die normale BR-Disk flachfällt und man seine Festplatten wieder auf andere Festplatten sichern muß. Nicht jeder hat Zugriff auf eine Tape-Library.

Brauchst du eigentlich unbedingt die 560GByte???
Weil aufblasen kannst du eine v.Disk ja jederzeit über die GUI, nur mit dem verkleinern sieht es schlecht aus. Ohne Hilfsmittel wie Imager, Backup oder Converter hast du dann einen langen Weg vor dir, der über das anlegen einer zweite v.Disk passender Größe und dann anschließendes Umkopieren führt...

[rprengel]

Ok,

endlich mal richtig abgeräumt.
Das System hat sich jetzt eh zerlegt. Ich ziehe die Daten raus und setzte das System neu auf.
Würde ich auf der sicheren Seite sein wenn ich 2 GB Files allocated wählen würde. Ich möchte die Dateien nicht grösser werden lassen um das System sicher über das Netzwerk sichern zu können. Zur Not halt auch per FTP/ NFS wenn nichts mehr geht und da ist bei 2 GB Schluss.

Gruß

Also ich bevorzuge immer Preallocated-Files, daß erspart jede Menge Ärger. Spätestens zum Shrinken, daß immer in zwei Stufen abläuft, werden im ersten Schritt die sogenannten Whipper-Files innerhalb der VM geschrieben. Dabei werden alle freien Bereiche und dazu zählen auch die als gelöscht markierte Sektoren (Stichwort Papierkorb), ausgenullt und dann im zweiten Schritt aus der v.Disk entfernt. Da aber jedes Dateisystem früher oder später fragmentiert, verteilen sich sämtliche VM-Daten über deren v.Disk und somit müssen die Whipper-Files auch über alle freien Bereiche der v.Disk geschrieben werden. In deinem Fall mußt du also mindestens noch den Platz frei haben, damit die v.Disk auf ihre voll Größe von 560GByte PLUS 2 GByte anwachsen kann.

Ob man die v.Disk dann noch in 2GByte-Häppchen aufteilt, bleibt jedem selbst überlassen. Es sind mir dadurch keine Performanceverluste bekannt geworden und ich mache daher in all meinen VMs davon reichlich Gebrauch. Eher vereinfacht man sich sogar noch die Sicherung. Die Häppchen von 2GByte kann man zur Not noch über mehrere DVDs aufteilen. Bei enbloc-Größen über 25GByte wird es dann schon schwerer, da selbst die normale BR-Disk flachfällt und man seine Festplatten wieder auf andere Festplatten sichern muß. Nicht jeder hat Zugriff auf eine Tape-Library.

Brauchst du eigentlich unbedingt die 560GByte???
Weil aufblasen kannst du eine v.Disk ja jederzeit über die GUI, nur mit dem verkleinern sieht es schlecht aus. Ohne Hilfsmittel wie Imager, Backup oder Converter hast du dann einen langen Weg vor dir, der über das anlegen einer zweite v.Disk passender Größe und dann anschließendes Umkopieren führt...

Das Teil ist mein MP3 Strorage inc. Itunes um Ipad und Iphone zu verwalten. Die Dreckssoftware will ich auf einem normalen System nicht haben. Leider arbeitet Itunes über Netzwerke noch mal wesentlich langsamer und schlechter als eh schon. Daher sind meie MP3s alle in dem System.

[rprengel]

Ok,

endlich mal richtig abgeräumt.
Das System hat sich jetzt eh zerlegt. Ich ziehe die Daten raus und setzte das System neu auf.
Würde ich auf der sicheren Seite sein wenn ich 2 GB Files allocated wählen würde. Ich möchte die Dateien nicht grösser werden lassen um das System sicher über das Netzwerk sichern zu können. Zur Not halt auch per FTP/ NFS wenn nichts mehr geht und da ist bei 2 GB Schluss.

Gruß

Also ich bevorzuge immer Preallocated-Files, daß erspart jede Menge Ärger. Spätestens zum Shrinken, daß immer in zwei Stufen abläuft, werden im ersten Schritt die sogenannten Whipper-Files innerhalb der VM geschrieben. Dabei werden alle freien Bereiche und dazu zählen auch die als gelöscht markierte Sektoren (Stichwort Papierkorb), ausgenullt und dann im zweiten Schritt aus der v.Disk entfernt. Da aber jedes Dateisystem früher oder später fragmentiert, verteilen sich sämtliche VM-Daten über deren v.Disk und somit müssen die Whipper-Files auch über alle freien Bereiche der v.Disk geschrieben werden. In deinem Fall mußt du also mindestens noch den Platz frei haben, damit die v.Disk auf ihre voll Größe von 560GByte PLUS 2 GByte anwachsen kann.

Ob man die v.Disk dann noch in 2GByte-Häppchen aufteilt, bleibt jedem selbst überlassen. Es sind mir dadurch keine Performanceverluste bekannt geworden und ich mache daher in all meinen VMs davon reichlich Gebrauch. Eher vereinfacht man sich sogar noch die Sicherung. Die Häppchen von 2GByte kann man zur Not noch über mehrere DVDs aufteilen. Bei enbloc-Größen über 25GByte wird es dann schon schwerer, da selbst die normale BR-Disk flachfällt und man seine Festplatten wieder auf andere Festplatten sichern muß. Nicht jeder hat Zugriff auf eine Tape-Library.

Brauchst du eigentlich unbedingt die 560GByte???
Weil aufblasen kannst du eine v.Disk ja jederzeit über die GUI, nur mit dem verkleinern sieht es schlecht aus. Ohne Hilfsmittel wie Imager, Backup oder Converter hast du dann einen langen Weg vor dir, der über das anlegen einer zweite v.Disk passender Größe und dann anschließendes Umkopieren führt...

Das Teil ist mein MP3 Strorage inc. Itunes um Ipad und Iphone zu verwalten. Die Dreckssoftware will ich auf einem normalen System nicht haben. Leider arbeitet Itunes über Netzwerke noch mal wesentlich langsamer und schlechter als eh schon. Daher sind meie MP3s alle in dem System.

Aktueller Status:

1)
Platten in Preallocated-Files gewandelt.
2)
Böser Patzer:
Der Antivir-Virenscanner hatte die vmdk Dateien noch nicht in der Ausschlussliste

Im Moment läuft das System schnell und rund.

Gruß

[Dayworker]

Aktueller Status:

1)
Platten in Preallocated-Files gewandelt.
2)
Böser Patzer:
Der Antivir-Virenscanner hatte die vmdk Dateien noch nicht in der Ausschlussliste

Im Moment läuft das System schnell und rund.

Gruß

Bei Punkt 2 solltest du auch noch die Datei "vmware-vmx.exe" auf eine hoffentlich vorhandene Prozeß-Ausschlußliste setzen. Nicht jede AV-Lösung arbeitet so intelligent und läßt Dateien von der Ausschlußliste dann auch im Arbeitsspeicher zufrieden.
Ich hatte den Fall mit Avira gehabt, daß die Ordner mit den VMDKs zwar auf den Ausschlußlisten für Scanner & Guard standen und ich die VM selbst, also den Prozeß "vmware-vmx.exe", in beiden Listen vergessen hatte. Das Ergebnis waren immer wieder kurzzeitig eingefrorene VMs, die vor allem bei Realtime-VMs, wie sie für Teamspeak/Ventrilo- oder allen Dedicated Game-Servern erforderlich sind, für einige Verstimmung sorgen.
Keine Ahnung wie MySQL oder andere DBs damit zurechtkommen. Von doppelten oder unvollständigen Einträgen bis zur kompletten Gefährdung der DB-Konsistenz könnte alles drin sein...