Gast verursacht bei Dateizugriffen extrem hohe CPU Last

[Rossi99]

Hi,

ich habe mich bereits durch sehr viele Seiten Forenthreads durchgewühlt, aber leider nichts passendes gefunden.

Die Konfiguration sieht wie folgt aus:

- Windows Server 2008 STD 64bit als Host, komplett durchgepatched
- Windows Server 2003 STD R2 32bit als Gast, komplett durchgepatched, 2 Cores zugewiesen, aktuelle VMWare Tools
- beide Systeme haben jeweile ein RAID1 für sich exklusiv zur Verfügung
- Hardware: HP Proliant DL180, 2GHz Core2Quad, 10GB RAM, e200i SAS Controller, 4 x 70GB 15k SAS Platten als 2 x RAID1

Die Offload Engine am NIC ist deaktiviert, ebenso der DOS Schutz am 2008.

Folgendes ist nun zu beobachten, wenn ich vom Gast aus auf eine Freigabe am 2008er zugreife:
Die Transferraten gehen nie wirklich ueber 15mb/s hinnaus. Wenn ich vom 2008 auf den 2003 kopiere erreiche ich eine CPU Auslastung von ca. 20%, was ich als ok bezeichnen wuerde. Wenn ich jedoch vom 2003 auf den 2008 kopiere, dann erhalte ich eine identische Transferrate, jedoch auf beiden Cores eine CPU Auslastung von 50-70% und das System ist per RDP kaum noch bedienbar. Unabhängig von der Auslastung passt hier definitiv auch die Transferrate nicht. Das Plattensystem schafft ca. 70-90MB/s beim Lesen/Schreiben. Selbst wenn man ein wenig Protokolloverhead mit rausrechnet, sind das immer noch ziemlich schlechte Werte.
Da ich natürlich versucht habe den Fehler einzugrenzen habe ich auch mal innerhalb der VM eine Datei kopiert. Dabei gingen beide CPUs auf fast 100% Auslastung und selbst hier kam ich auf keine wesentlich höhere Transferrate.

Testweise bin ich nun mal hingegangen und habe es mit Hyper-V versucht. Dabei habe ich folgendes Ergebnis erhalten: Beim Kopieren vom Host auf den Wirt und umgekehrt bekomme ich nach wie vor eine recht hohe Auslastung von ca. 50% auf einem Core, dafür in der Spitze aber auch Transferraten von bis zu 90MB/s. Ein Kopiervorgang innerhalb der VM verursacht hier nur ein paar Prozent CPU Last und die Transferrate liegt bei ca. 30MB/s. IMO sind das so in etwa die Werte, die ich erwarten würde und mit denen ich bei der Auslegung der Hardware auch gerechnet habe. Während des gesamten Testens war das System auch durchgehend noch flüssig zu bedienen.

Hat jemand ein Idee in welcher Richtung ich den Fehler suchen kann? Prinzipiell würde ich nämlich schon gerne bei vmware bleiben. In dem aktuellen Zustand kann ich es jedoch nicht verwenden.

Gruss Rossi

[e-e-e]

Hallo,

ein Hauptproblem wird sein, dass Du alle vorhandenen Cores an die VM vergeben hast. Dadurch muss sich der Host, wenn er Arbeit hat, immer einige Takte dazwischenklemmen, und in der Zeit läuft Deine VM überhaupt nicht, weil die nur läuft wenn sie beide Cores zur Verfügung hat.

[Rossi99]

Das ist ein Quadcore. Ich habe der VM 2 Cores zugewiesen. Testweise habe ich es aber auch schon mal auf einen Core reduziert mit dem Ergebnis, dass der eine Core dann zu fast 100% ausgelastet war. :/

[Dayworker]

Also erstmal ist ein Raid1 meistens kontraproduktiv für die Geschwindigkeit, da zuerst auf beide Laufwerke geschrieben werden muß und dann der Abgleich erfolgt.

Die große Schwachstelle bei VMware-Server heißt Festplattenzugriff. Da hier alle Zugriffe auf SW umgesetzt werden, dauern manche Aktionen etwas länger. Ein bisken Abhilfe läßt sich je nach Host-OS über die Konfigurationsdateien schaffen. Damit verhinderst du schonmal eine Vorbelastung des I/O-Nadelöhrs durch etwaiges Swappen.

mainMem.useNamedFile = "false"
Damit wird verhindert, daß ein Memory-File angelegt wird. Es hat aber seine Ursache in der Art und Weise wie VMware mit "mmap" wohl Speicher anfordert. Normalerweise legt VMware im in jeder gestarteten VM auch noch ein *.mem-File in der Größe des VM-Arbeitsspeichers als Disk-File an. Dadurch dauert der erste Start einer VM gewöhnlich sehr lange, da dieses File angelegt und auf Konsistenz überprüft werden muß. Wenn dieses mit der Einstellung "false" abgelehnt wird, nutzt VMware das Swap-Gerät des Host-OS (Linux = /tmp, Windows = pagefile.sys).

Die Einstellung >>mainMem.useNamedFile = "false"<< kann auch in die config.ini eingefügt werden, dann gilt sie automatisch für alle VM's und einen Nachteil hab ich bis jetzt nicht gefunden.

Diese Zeilen sollte man fuer meinen Geschmack nicht in die vmx - sondern in die config.ini schreiben

prefvmx.useRecommendedLockedMemSize = "TRUE"
prefvmx.minVmMemPct = "100"
mainMem.partialLazySave = "FALSE"
mainMem.partialLazyRestore = "FALSE"

Der Grund weshalb Hyper-V anscheinend so viel zügiger ist, liegt wahrscheinlich in der alleinigen Ausrichtung auf Windows-Gäste und der damit möglichen Optimierung auf bestimmte HW/SW-Kombinationen. Damit eine VM auf Linux- und Windows-Server2 läuft, muß jede VM natürlich komplett vom Host und seiner HW getrennt/unabhängig sein. Es wäre für mich daher durchaus denkbar, daß MS die Disk-Adapter einer VM komplett in Hardware durchreicht.
Mangels geeigneter Hard- und Software kann ich das leider nicht überprüfen.

[Rossi99]

Erst einmal danke fuer die Antwort!

Ich werde das mit deinen Tips mal durchtesten.

Bei dem Controller handelt es sich uebrigens um einen Hardware RAID Controller. IMO sollte das doch eigentlich keinen Einfluss auf die Performance haben oder?

Hyper-V unterstuetzt uebrigens auch Linux, wenn auch nur fuer SUSE mit Support. Andere Distributionen laufen allerdings wohl auch.

[Dayworker]

Okay, bei einem HW-Controller sieht es etwas freundlicher aus. Ich würde trotzdem so wenig I/O-Grundlast wie möglich in der VM erzeugen und erstmal die Einstellungen probieren.

Wie ich erst jetzt gelesen habe, hatten MS und Novell schon vor etwas längerer Zeit eine Kooperation vereinbart. Das erklärt dann auch die Unterstützung von Suse. Interessant wäre daher der testweise Einsatz einer anderen Distribution.

[Rossi99]

Noch eine Frage: Gelten die Konfigurationsanpassung sowohl fuer die 2er als auch fuer die 1er Version?

[Dayworker]

Kurze Antwort, JA.

[Tschoergez]

noch ein paar Tipps:
hast Du die VMware tools installiert? die bringen verbesserte (paravirtualisierte) Treiber für die virtuellen SCSI-Adapter mit, was den CPU-overhead senkt...

und: passt der HAL im Gast zur Anzahl der verwendeten vCPUs? (Siehe suchfunktion)

viele grüße,
jörg

[Rossi99]

Also die Tools verstehen sich von selbst. Die sind natürlich drauf.

Ich hatte dem System bei der Installation bereits 2 Cores zugewiesen. Daher gehe ich mal davon aus, dass die HAL passt. Lediglich beim Testen bin ich dann noch mal zurück auf einen Core gegangen. Dort wird die HAL sicherlich dann nicht gepasst haben.

Da ich Zugriff auf einige recht ähnlich angelegte Systeme habe (1 x File- und Terminalserver auf unterschiedlicher physikalischer Hardware mit 1GBIT, 1 x Fileserver mit einem virtualisierten Terminalserver unter der 1er Version und nun die gleiche Konstellation unter der 2er Version), bin ich hier aktuell fleissig am Testen. Dabei scheint zumindest die hohe CPU-Auslastung beim Kopieren innerhalb der VM wirklich nur bei der 2er aufzutreten. Eine recht schlechte Netzwerkperformance habe ich jedoch auch bei der 1er. Teilweise liegt die erreichte Transferrate bei 1/3 bis 1/4 von dem, was das Plattensystem liefern koennte. Kann es sein, dass wenn die NIC physikalisch mit 100MBit angebunden ist, dass ich dann im Bridgemodus trotz der 1GBIT der virtuellen NIC nur in etwa die 100MBit erhalte?
Wobei das eigentlich auch nicht sein kann, weil dann duerfte eigentlich nie der DOS Schutz von Windows greifen, was er aber definitiv in dieser Konfigurationsvariante (100MBit physikalisch / 1GBIT virtuell) bei mir jedesmal getan hat.

[Dayworker]

Die Angabe der Nic-Geschwindigkeit in der VM sind nur Schein. Du kannst maximal die gleiche Datenrate wie beim Host erwarten.
Sehr schön läßt sich das beobachten, wenn du einer VM keine "e1000" sondern nur die "vlance" alias "AMD PCNET 32" als Nic-Adapter zuweist. Dann siehst du trotz 1Gbit-Nic im Host trotzdem nur 10Mbit im Gast.