Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

VMWare Server 1.04 Disk I/O - Riesige Wait-Time

Hilfe bei Problemen mit der Installation oder Benutzung des VMware GSX Server und VMware Server 1.

Moderatoren: Dayworker, irix

Member
Beiträge: 4
Registriert: 14.09.2007, 18:25

VMWare Server 1.04 Disk I/O - Riesige Wait-Time

Beitragvon josen » 03.03.2008, 13:24

Hallo Forum,

seit einigen Tagen habe ich nach 'top' und 'atop' eine sehr große Zeit an Wait (10-50%), also Wartezeit der CPU auf das Festplatten-Subsystem. Atop gibt gar 100% Belastung der Festplatte aus.

Auf dem Core2Duo 4GB RAM, 2x S-ATA Host laufen zur Zeit nur drei virtuelle Maschinen.

Ein Test mit `spew` zeigt allerdings eine Geschwindigkeit von 25Mb/sec direktes I/O an, auf dem laufenden System (soviel kann die HD, nicht so stak ist sie ausgelastet).

Was kann ich tun um das Problem weiter zu suchen? Stehe auf dem Schlauch.

Alle VMs sind auf der selben Festplatte. Nach dem Test mit 'spew' sinkt die Wartezeit auf 0,5-5%.


Grüße,
josen

Member
Beiträge: 120
Registriert: 28.02.2008, 15:30
Wohnort: Linz

Beitragvon CLSsupport » 03.03.2008, 14:20

Hallo josen

Ich kann dir noch keine Lösung anbieten bin aber an ähnlichen Dingen dran.
Welches HOST OS läuft bei Dir ?

Man sagte mir - Host soll ein Plattensystem haben und VMs ein getrenntes - am besten jede VM ein eigenes, was sich nicht immer machen lässt.
Probier mal den HOST von einer externen HDD aus zu starten - am Besten wäre da eSATA

Michael

Member
Beiträge: 4
Registriert: 14.09.2007, 18:25

Beitragvon josen » 03.03.2008, 16:33

Debian "etch" 4.0r3 mit selbstkompiliertem Kernel 2.6.

Ich bin zur Zeit dabei passende Debugging-Werkzeuge zu suchen, die mir die Transaktionen der VMs genau aufzeigen können und wo die wait()'s auftreten.

Vielleicht ist es interessant, die Bemühungen zu koordinieren? Wir sind sicher nicht die Einzigen mit dem Problem.

Grüße

Member
Beiträge: 49
Registriert: 20.07.2003, 08:18

Beitragvon gbl » 05.03.2008, 16:35

Nein, du bist nicht alleiner mit deinem Problem. Ich hab's hier auch.

Meine Eckdaten:

HP ML350G5. 6GB Ram, P400/512er Controller, SAS Platten, 1x DualCore 2GHz
CentOS5 64Bit und VMWare 1.0.4.

Linux vmlin1 2.6.18-8.1.14.el5 #1 SMP Thu Sep 27 19:05:32 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux

1x Windows 2003 Terminalserver -> 3GB Ram, 2CPU
1x MiniFileServer (2003) -> 700MB Ram, 1CPU
1x WSUS -> 700MB Ram, 1CPU

Unter Tage gibt's soweit keine Probleme. In der Früh müssen der File und der WSUS abgedreht werden, da der Terminalserver extreme Performanceprobleme hat.
Nach ca. 30 min. kann man die anderen wieder starten.

Null Plan.

Ich hab' mal MUNIN installiert. Vielleicht gibts damit einen Hinweis.

Member
Beiträge: 6
Registriert: 18.03.2008, 08:56

Beitragvon dirk12345 » 18.03.2008, 09:10

Hallo zusammen,

ich leide auch unter hohen I/O-Waits 10%-50%. :(

System:
Intel Xeon CPU Quad Core 2.33GHz
8 GB RAM
3ware 9650SE-8LP (SATA Raid Controller)
CentOS 5 (64bit)
VMware 1.0.4

Als Gastsystem laufen:
1x Debian Linux
1x Windows XP
1x Windows 2003 Terminal Server
1x Windows 2000 Server

Die CPU langweilt sich eigentlich, aber die hohen I/O Waits führen zu einer schlechten gesamt Performance.
Das Host OS läuft auf demselben Raidset, aber andere Partition, wie die VM Gastsysteme.
Das ist natürlich nicht optimal, aber ein Wechsel des Setups wäre mit einem "grösseren" Aufwand verbunden und Kosten für zusätzliche Platten. Da wären Erfahrungswete wünschenswert.

Ich hab leider die nötige Hardware nicht vorrätig...

Habt Ihr die Host-/Gastsysteme auf demselben Raidset laufen?

Member
Beiträge: 49
Registriert: 20.07.2003, 08:18

Beitragvon gbl » 18.03.2008, 11:08

Nachdem ich Munin nun einige Zeit am Laufhatte, konnte ich feststellen:
    Der HOST wollte 7GB RAM verwenden obwohl nur 5GB vorhanden sind.
    Irgend ein Prozess vernichtet in der Nacht ca. 512MB Ram (Memoryleak)
    Durch einen Restart des HOSTS waren alle Probleme weg.


Was mit das RAM vernichtet, weis ich nicht. Ich tippe mal auf den SAMBA Server, zumal dieser Server auch als Backup2Disk eines anderen Servers dient. Die Uhrzeiten der Sambaaktivität und des Memoryleaks passen zumindest zusammen.

PS:
OS und VM's liegen bei mir auf getrennten RAIDs.

Member
Beiträge: 120
Registriert: 28.02.2008, 15:30
Wohnort: Linz

Beitragvon CLSsupport » 18.03.2008, 21:19

Ich frag mal unwissend:

Was ist MUNIN ?
Wo hast du Samba laufen - direkt am CentOS ?

@all here - mit i/o wait Problemen
Wer hat bereits sämtliche config und vmx Parameter gesetzt, damit die VMware NICHT den einzelnen VMs kein RAM wegnimmt, kein mem pagingfile anlegt und den VMs echtes pRAM fix zuweist ?

Dann sind wenigstens alle Disk I/Os ausschliesslich durch VMDK Plattenzugriffe verursacht und keinesfalls durch .mem Zugriffe.

Michael

Member
Beiträge: 6
Registriert: 18.03.2008, 08:56

Beitragvon dirk12345 » 19.03.2008, 10:12

CLSsupport hat geschrieben:@all here - mit i/o wait Problemen
Wer hat bereits sämtliche config und vmx Parameter gesetzt, damit die VMware NICHT den einzelnen VMs kein RAM wegnimmt, kein mem pagingfile anlegt und den VMs echtes pRAM fix zuweist ?
l


Ich frage auch mal unwissend, welche wären das? :)

Prinzipiell kann ich aber sagen, dass der VMware Server genug RAM hat und den SWAP Space nicht nutzt. Der pRAM reicht dem momentan vollkommen aus.

Member
Beiträge: 120
Registriert: 28.02.2008, 15:30
Wohnort: Linz

Beitragvon CLSsupport » 19.03.2008, 14:05

Ich möcht mich nicht mit fremden Federn schmücken.

Findest du auf der homepage von continuum
http://sanbarrow.com/vmx/vmx-config-ini.html#Swapping

Und wir habens bereits diskutiert.
http://vmware-forum.de/viewtopic.php?t=11288&highlight=

Was davon auch auf LINUX HOSTS zutrifft kann ich (noch) nicht genau sagen.
Die settings in der vmx müssten jedoch das VMware memory swapping "grösstmöglich" unterbinden.

Michael


Zurück zu „VMserver 1 und GSX“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast