Performanceprobleme bei der Virtualisierung

Virtualisierung ist eine klasse Sache, um mehrere Betriebssysteme auf einer Hardware zu Produktions- oder Testzwecken zu fahren. Ich selbst nutze diesen Ansatz, um diverse Betriebssysteme für Tests auf einem Host einzurichten. Allerdings hatte ich seit längerem das Problem einer sehr schlechten Performance bei der Virtualisierung. In diesem Beitrag möchte ich einen Blick auf die Frage werfen, was man tun kann, wenn es Performanceprobleme bei der Virtualisierung gibt.

Eigentlich beschäftige ich mich seit über 10 Jahren mit dem Thema Virtualisierung, und 2001 ist mein erstes (und einziges) Buch über VMware Workstation zu diesem Thema erschienen. In der Rubrik Virtualisierung finden sich folgerichtig einige Beiträge zu Fragen rund um die Virtualisierung mittels verschiedener Lösungen (VMware, Virtualbox, VMLite, Win VPC).

Und was ist mit der Performance?

Allerdings gab es da eine Sache, über die ich bisher nichts geschrieben habe: Die Frage nach der Performance virtueller Maschinen. Eigentlich sollte man ja problemlos zwei oder drei virtuelle Maschinen mit Gastsystemen aufsetzen und ausführen können, ohne dass es Probleme gibt. Aber so richtig flott wollten die VMs bisher bei mir nicht laufen. Klar, eine VM in Virtualbox oder VMware Server oder VMware Workstation war nutzbar. Aber oft zuckelte das virtualisierte Gastsystem gemächlich daher – jedenfalls war kein Vergleich mit realer Hardware möglich. Dabei lagen mir die enthusiastischen Erfahrungen mancher "Anwender" bezüglich Virtualisierung diverser Server auf einer Hardware in den Ohren.

In den Anfangstagen unter Windows XP mit 450 MHz Pentium-Maschinen und 750 MByte RAM schob ich die mangelnde Leistung auf die schwachbrüstige Hardware (aber es gab damals wenig besseres). Dann kam Windows Vista, 2 – 3 GByte Arbeitsspeicher und eine DualCore-CPU. Da auch dort keine Virtualisierungsunterstützung per Hardware vorlag, schob ich die mangelnde Leistung auf die softwaremäßig Virtualisierung. Nachdenklich wurde ich aber, als ich auf ein neues System mit QuadCore-CPU samt VT-Unterstützung umstieg. Die SATA-Festplatte war mit satten 1 GByte ausgestattet und der Arbeitsspeicher auf 4 GByte aufgerüstet. Da sollte die Virtualisierung der Gastsysteme doch recht flott über die Bühne gehen.

War aber nicht, im Gegenteil. Unter 32-Bit-Windows 7 hatte ich teilweise massive Hänger und Aussetzer, sowohl im Gastbetriebssystem als auch auf dem Host. Ein Wechsel zu einem 64-Bit-Windows 7 schien kurzzeitig Abhilfe zu schaffen. Aber so richtig rund lief es nicht wirklich. Mikrohänger schob ich auf fehlerhafte Chipsatztreiber, hatte ich doch unter [2] genau diese Erfahrung als Ursache ausgemacht. Nach Installation der korrekten Chipsatztreiber lief das Hostsystem auch einwandfrei. Nur bei der Virtualisierung gab es ständig Probleme. Mal startete die VM recht zäh, mal gab es Mikrohänger bei Internet Explorer, Thunderbird oder anderen Windows 7-Anwendungen auf dem Host. Zwei oder mehr VMs parallel ausführen war kaum möglich.

Irgendwie scheine ich dann bei meinen Experimenten zur Ursachensuche auf Abwege geraten zu sein. Nachdem ich Windows 7 mehrfach neu aufsetzte, hatte ich irgendwann sogar eine Situation, in der ich mit Windows Virtual PC, VMware Player 3 und VirtualBox 3.01 zwei oder drei VMs parallel mit nutzbarer Performance ausführen konnte. Nach der Installation von Windows 7 mit integriertem SP1 rauschte ich aber wieder in die Situation, dass die Gast-Betriebssysteme und auch der Host massive Performanceprobleme zeigten. Der Wechsel zu einer alten Sicherung ohne SP1 schien das Problem zunächst zu beseitigen, bis nach einer Updatereihe wieder Performanceprobleme auftraten.

Ursachenanalyse ist angesagt

Nachdem ich mit diversen Virtualisierungslösungen massive Performanceprobleme hatte, war guter Rat teuer. Die Vermutungen reichten von Hardwareproblemen über fehlerhafte Konfiguration des Systems bis hin zu Konflikten durch Installation mehrerer Virtualisierungslösungen. Unter [3] hatte ich sogar einen Beitrag verfasst, der mögliche Ursachen für VMware Workstation 7 skizzierte. Und nach diesen Ansätzen hatte ich vermeintlich sogar partiell Erfolge – die sich aber als temporär erwiesen. Dadurch wurde mir hier das Thema Virtualisierung etwas verleidet, da ich auf dem Produktivsystem bei laufender Virtualisierung nicht mehr arbeiten konnte.

Irgendwann kam ich auf die Idee, nicht mehr nach Virtualisierungsproblemen bei VMware, Virtualbox oder Virtual PC sondern globaler nach Performanceproblemen bei der Virtualisierung zu suchen. Und dabei stieß ich auf die Fundstelle unter [1]. In einem White Paper beschreibt ein VMware-Mitarbeiter, wie man Performance-Probleme analysiert. Er trennt dabei das Ganze in vier Bereiche, die separat zu analysieren sind: CPU-Auslastung, Memory-Auslastung, Speicherzugriff auf Disk und Disk I/O. So etwas hatte ich zwar auch unter [3] adressiert, aber nicht systematisch durchgezogen. Also auf ein neues ….

Meine Diagnose Schritt für Schritt: CPU-Last und RAM-Belegung

Zuerst habe ich bei laufender virtueller Maschine nachgesehen, ob Speichermangel oder zu hohe CPU-Auslastung die Ursache sein konnten. Hierzu lässt sich der Taskmanager mit der Registerkarte Leistung verwenden.

Mehrfache Messungen zeigten, dass die vier Kerne eigentlich nur selten ausgelastet waren und nicht der Grund für die Performance-Probleme sein konnten. Der verfügbare Arbeitsspeicher war mit 4 GByte zwar nicht üppig, aber oft wurden 1 GByte und mehr als verfügbar ausgewiesen. Gleiches Bild, wie es sich auch in der Vergangenheit darstellte. Das konnte nicht wirklich die Ursache für die Hänger und Freezes sein, denn ich hatte auch schon Probleme, wenn ich zwei Windows XP-Gastsysteme mit 512 MByte Ram oder Androids mit je 256 MByte RAM parallel laufen ließ.

Hängende Prozesse analysieren

Da mir Anwendungen wie der Internet Explorer sogar auf dem Host immer wieder kurzzeitig einfroren, habe ich den Ressourcenmonitor über die gleichnamige Schaltfläche der Registerkarte Leistung des Taskmanagers aufgerufen. Auf der Registerkarte Übersicht wird ein hängender Prozess mit roter Schrift angezeigt. Dann lässt sich über den Kontextmenübefehl Warteschlange analysieren nachschauen, warum der Prozess hängt.

In allen Fällen erhielt ich den Hinweis auf wartend auf E/A (im Netzwerk oder sonst wo). Hier schob ich die Ursache erneut auf den Chipsatz- oder LAN/WLAN-Treiber. Da aber die Treiber aktuell waren, führte dies nicht weiter.

I/O-Analyse für Datenträger

Erst das White Paper unter [1] brachte mich zum Nachdenken. Ich hatte die Partition für die Virtualisierungsdateien auf dem Systemlaufwerk angelegt und die Probleme traten bei allen Virtualisierungslösungen auf. Also kam ich auf die Idee, die I/O-Last bei Datenträgerzugriffen zu analysieren. Auch diese Analyse lässt sich auf die Schnelle mit dem Ressourcenmonitor durchführen. Die Registerkarte Datenträger enthält die erforderlichen Angaben.

Im obigen Bild lässt sich erkennen, dass der VMware-Prozess eine große I/O-Last auf einem SATA-Kanal erzeugt, der die Übertragungskapazität sprengt. Dadurch steigt die I/O-Warteschlangenlänge auf 5 bis 10. Folglich erhält auch der Host nicht mehr genügend Bandbreite, um auf das Systemlaufwerk zuzugreifen. Die Ursache für meine Performanceprobleme war gefunden. Müßig zu erwähnen, dass sich auch bei anderen Virtualisierungslösungen wie Virtualbox oder Windows Virtual PC ein ähnliches Bild zeigt.

Eine überraschende Lösung

Nun war noch unklar, ob die Chipsatztreiber, Treiber der VMs oder sonst etwas den Flaschenhals darstellten. Denn immerhin hatte ich das System ja phasenweise so konfiguriert, dass trotz dieser Konstellation ein Arbeiten mit zwei oder drei VMs möglich war.

Da Windows 7 ohne Virtualisierung wie "ein Champ" funktionierte, kam mir eine Idee: Konnte es sein, dass die I/O-Last einfach das Limit des SATA-Kanals überschritt? Bevor ich wieder mit Neuinstallation, Chipsatztreiber-Aktualisierung etc. experimentierte, wollte ich mal einen anderen Ansatz testen. Ich verfüge über eine externe SATA-Platte für Backups, die über einen Datenhafen per eSATA eingebunden werden kann. Also habe ich diese kurzerhand an den eSATA-Anschluss gehängt und ein paar VM-Dateien auf diese Festplatte verschoben. Danach wurden die virtuellen Dateien in VMware Workstation eingehängt und anschließend nacheinander mehrere VMs gestartet.

Die obige Analyse der Datenträgerzugriffe mit dem Ressourcenmonitor zeigt zwar erneut eine hohe I/O-Last auf der zweiten Festplatte mit den Virtualisierungsdateien. Aber die erste Festplatte mit dem Systemlaufwerk hat noch freie Kapazität. Da beide Datenträger über separate SATA-Kanäle angesteuert werden, ist dies unkritisch.

Dieser Ansatz wirkte Wunder! Das Verhalten des Systems entsprach nun auch meinen Erwartungen: Der Host war weiterhin problemlos nutzbar und es konnten zwei, drei und mehr Gastbetriebssysteme parallel in VMware Workstation ausgeführt werden. Die VMs bremsten sich zwar beim Start gegenseitig etwas aus und irgendwann gab es auch kurzzeitig Speicherengpässe. Aber dies gab sich, sobald die Gastbetriebssysteme hochgefahren waren. Umschalten zwischen den Gästen, der Wechsel auf den Host, alles war plötzlich keine Problem mehr. Sobald ich zu einer VM umgeschaltet hatte, erhielt diese entsprechende Ressourcen und war problemlos zu nutzen.

Ich für meinen Teil habe damit die Lösung für die Performance-Probleme auf dem konkreten System gefunden. Offenbar haben die Hersteller von Virtualisierungslösungen, angefangen von Microsoft über VMware bis hin zu Oracle da ebenfalls keinen Blick darauf. Denn wie wäre es sonst zu erklären, dass die gängigen Virtualisierungslösungen die Dateien neuer virtueller Maschinen standardmäßig auf dem Windows Hostlaufwerk erstellen wollen?

Es mag sein, dass dies nicht auf allen Systemen ein Problem darstellt und die I/O-Leistung der SATA-Kanäle samt Festplatten höher sind. Aber im Nachhinein erinnere ich mich, bei Recherchen in VMware-Foren durchaus den einen oder anderen vagen Hinweis in diese Richtung gelesen zu haben. Der oben skizzierte Diagnoseverlauf zeigt mir auch, dass es mitunter ganz schön schwierig sein kann, die richtigen Schlüsse zu ziehen. Vermutlich habe ich vor lauter Bäumen zeitweise den Wald nicht mehr gesehen und einfach zu stark in technischer Ausrichtung nach Fehlern in einem bestimmten Produkt bzw. in den Chipsatztreibern gesucht, statt mich ein paar Minuten hinzusetzen und die Randbedingungen sauber zu analysieren. Aber wie sagt schon Goethe "Es irrt der Mensch, so lang er strebt" …

Links:
1: VMware Performance Monitoring to Avoid Slow VMs
2: Ständige "Freezes" in Windows 7
3: Performanceprobleme bei VMware Workstation 7
4: Performance Monitoring and Analysis