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.
Anzeige
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.
Anzeige
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
Anzeige
Dieser Beitrag ist zwar schon eineinhalb Jahre alt, doch das Problem ist ein viel älteres: Ob ich nun eine 100 GB-Platte oder eine 2 TB-Platte im System habe, alles auf dieser Platte laufen zu lassen ist selbst bei sehr schnellen Systemen nicht das Optimum. Ich habe bereits in Zeiten der 486er-Prozessoren begonnen immer mit mindestens zwei Festplatten zu arbeiten. Auf der zweiten befand sich übrigens (trotz diverser Unkenrufe – man möge doch Windows nicht die Verwaltung eines zusätzlichen Laufwerkes zumuten, das koste mehr Performance als das Zweitlaufwerk an Geschwindigkeit bringe) immer die Auslagerungsdatei. Weiters wurde dieses Laufwerk meistens als Arbeits- oder Datenlaufwerk eingesetzt, sodass auch bei einem totalen Crash (welchen ich bis heute nicht in der Form erlebt habe, dass ich ein System aufsetzen musste) die Daten erhalten blieben.
Als dann die Hardware erschwinglicher wurde, kam noch ein PCI-Controller mit weiteren Laufwerken dazu und auch das schwachbrüstigste System lief sehr gut.
Heute habe ich zwar beruflich einen i7-Rechner mit 32 GB Arbeitsspeicher, einem RAID 1-Verbund mit je 1 TB für das System, 5 TB RAID 5 für diverse Arbeitsdateien sowie drei gesonderte Laufwerke zu je 2 TB zur Verfügung, doch an der obigen Arbeitsweise (insbesondere im Privatbereich) hat sich nichts geändert. Virtuelle Maschinen liegen nicht auf der Systempartition, sondern sind je nach Umfang und Einsatz auf verschiedenen Platten (nicht Partitionen) verteilt. Das ergibt eine Performance wie beim physischen System.
Die Frage nach der Überlegung der Hersteller, warum diese die Dateien ihrer Produkte auf dem Systemlaufwerk ablegen wollen, stellt sich bei mir schon lange nicht mehr, es dürfte ihnen schlicht und einfach egal sein. Microsoft würde wahrscheinlich annehmen, dass die User überfordert sind (deshalb werden dort immer noch standardmäßig System und Daten auf der gleichen Partition untergebracht).
Warum Sie als Profi für die obige Lösung allerdings so lange gebraucht haben, überrascht mich doch ein wenig, denn dazu bedarf es doch nur ein wenig des berühmten (jedoch in freier Wildbahn immer seltener gesichteten) "Hausverstandes".
Trotz alledem – ich lese Ihre kompetenten Artikel sehr gerne und freue mich besonders, dass Sie sich den Produkten der Firma Paragon so umfangreich widmen, denn diese werden meines Erachtens völlig zu Unrecht in diversen Foren verteufelt. Die Oberfläche ist sehr bedienerfreundlich, die Funktionen sind vollständig und ausgereift. Ich habe mit diesen Programmen schon Systeme virtualisiert oder auf andere Hardware portiert, was mit VMWare-Produkten oder anderen "Tools" nicht oder nur mit einem wesentlich höherem Aufwand möglich war.
Wie lautet die Konsequenz wenn nur EINE Festplatte zur Verfügung steht (z.B. bei einem Notebook): Die Dateien der VM auf einer anderen Partition (als die Dateien des Host-Systems) lagern? Genügt es, Gast und Host auf jeweils separaten Partitionen zu lagern oder bedarf es zweier physischer Laufwerke (Festplatten)?
Die Konsequenz lautet:
– entweder einen sehr schnellen SATA 3-Controller mit schneller Festplatte/SSD
– oder die I/O-Last auf zwei SATA-Kanäle, sprich: zwei Festplatten aufteilen
Die Aufteilung auf Partitionen ändert ja nichts an der Last auf dem I/O-Kanal. Im Gegenteil: Die Kopfbewegungen durch das ständige Positionieren zwischen Host- und Gast-Betriebssystem-Dateizugriffen verringern sogar die Performance.
PS: Den Link zu einer erst im Entstehen begriffenen Website habe ich rausgenommen. Ich möchte Ross und Reiter kennen, wenn Kommentare hier eingestellt werden. Es gibt zu viel Versuche, verkappten SPAM hier einzustellen.
Ich finde, dass das Wort "SATA-Kanal" im Artikel den falschen Wortlaut darstellt.
SATA 2 (3 Gbps) schafft bis zu 300Mbyte Datendurchsatz. Real gemessen habe ich bis zu 280MB/s lesend.
Allerdings kann man den oben beigefügten Diagrammen entnehmen, dass dieser Wer bei weitem nicht erreicht wird, wodurch der SATA-Kanal nicht der limitierende Faktor sein kann.
Zumal Handelsübliche Festplatten, keine SSDs!, bei weitem keine 300MB/s erreichen.
Die richtige Bezeichnung des Problems wäre, dass die Festplatte nicht genügend Leistung (IOPs) bietet, sodass die entsprechenden Programme warten müssen, dass diese lesen/schreiben dürfen.
Die I/O Performance einer herkömmlichen HDD mit 7200 RMP liegt so im Bereich von 120 IOPs.
Das Problem, was sich daraus ergibt, ist der Fakt, dass sowohl Host OS und jede VM selbst im Leerlauf schreiben und lesen. Mit jeder weiteren VM steigt diese Summe nun. Irgendwann ist die Festplatte an ihrem Limit und es kommt zu ruckler.
Dabei ist der Internet Explorer gar nicht so untypisch, da hier Elemente einer Webseite auf der Festplatte gecached werden und bei einem Zugriff auf eine neue Seite geladen werden (viele I/Os).
Durch das hinzufügen einer zweiten HDD, nicht durch das hinzufügen eines 2. SATA Kanals, wird Abhilfe geschaffen, denn:
Das Host OS hat nun etwa die 120 IOPs für sich alleine. Hier kommt es somit zu keinen Engpässen.
Lediglich die VMs müssen sich die weiteren 120 IOPs einer zweiten Festplatte teilen.
Dadurch entsteht in Summe somit theoretisch eine in etwa verdoppelte Performance.
Btw.: Eine SSD hätte in diesem Sogar weit aus mehr geholfen, denn diese erreichen mitlerweile ganz Problemlos >10000 IOPs.
Ob eine SSD wirklich hilft ?
Ich bin auf diesen Artikel gestoßen, weil ich mich gewundert habe, dass eine große Excel Tabelle in meiner VM beim Scrollen merklich ruckelt. Auf dem Host passiert das nicht.
Eigentlich dachte ich, ich hätte alles richtig gemacht. Hexacore CPU, 32GB DDR4 und eine 500GB SSD. Sicher, das ist schon viel besser als früher, als die VMs wegen Platzmangels auf einer Magnetfestplatte gespeichert waren.
Nach dem ich den Artikel gelesen habe, habe ich mir auch mal den Resourcenmonitor angeschaut und tatsächlich, wenn ich in der VM in der Excel Tabelle scrolle, rennt die SSD vom Host ans Limit …
Möglicherweise ist auch das AHCI Protokoll das Problem. So wie ich es verstehe, sollte NVMe besser geeignet sein, nicht weil es schneller ist, sondern weil es mehr Befehle parallel überträgt.
Jedenfalls werde ich mir eine zweite SSD für die VMs anschaffen. Und da mein Mainboard die Möglichkeit bietet, eine NVMe Karte mit 4 PCIe 3.0 Lanes anzuhängen, werde ich mich wohl dafür entscheiden und somit SATA und AHCI komplett umgehen.
Konrad
Warteschlangen sind immer wieder der Klassiker… sensible Gemüter hätten das allerdings schon gehört, bevor sie das gemessen hatten und der wahre Betriebsystemfreak des auslaufenden 20. Jahrhunderts hatte 8 Festplatten in einem ERP/Webshop System:
1) Betriebsystem 2) IIS6 und Web-Frontend 3) sql server 4) SQL Daten 5) swap 6) Dateien des ERP Systems 7) alles was temp ist 8) Log des SQL Servers