Virtuelle Maschine unter Hyper-V ist langsam: Prozessor, Arbeitsspeicher und Datenträger prüfen
Die Messung im Gast führt in die Irre. Auf dem Host gibt es für jede der vier Ressourcen einen Zähler mit einem klaren Schwellenwert, ab dem eine Maßnahme fällig ist.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Im Gast sieht alles ruhig aus, und trotzdem hakt es
Der Reflex ist, sich auf der langsamen Maschine anzumelden und den Task-Manager zu öffnen. Was dort steht, ist nicht falsch, aber es beantwortet die Frage nicht. Ein Gast sieht seine virtuellen Prozessoren und die Zeit, in der er laufen durfte. Er sieht nicht, wie lange er darauf gewartet hat, dass ein logischer Prozessor des Hosts frei wird. Ein überbuchter Host erzeugt deshalb im Gast das Bild einer Maschine, die kaum etwas zu tun hat, während Anwender berichten, dass alles zäh ist.
Der zweite Irrtum betrifft den Arbeitsspeicher. Wenn im Gast noch freier Speicher angezeigt wird, gilt die Sache oft als geklärt. Auf einem Host mit dynamischem Arbeitsspeicher ist das aber genau die Konstellation, in der es klemmt: Der Verwalter für dynamischen Arbeitsspeicher verteilt zwischen den Maschinen, und wenn auf dem Host wenig verfügbar ist, bekommt eine Maschine weniger, als sie gerne hätte, ohne dass im Gast eine Warnung erscheint. Der aussagekräftige Wert steht deshalb auf dem Host.
Der dritte Punkt ist die Zuordnung. Auf einem Host mit dreißig Maschinen ist die Frage selten, ob es klemmt, sondern welche Maschine wen bremst. Eine einzelne Maschine, die den Datenträger sättigt, macht alle anderen langsam, und im Gast dieser anderen sieht man davon nichts außer langen Antwortzeiten. Deshalb beginnt die Eingrenzung immer mit den Zählern für den gesamten Host und geht erst danach auf die einzelne Maschine.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Sechs Fälle und ihre Behandlung
Jeder Fall hat ein Erkennungsmerkmal, eine Ursache und eine Maßnahme. Wer die Merkmale kennt, misst gezielt statt breit und kommt an einem Vormittag zu einem Ergebnis, das sich belegen lässt.
Symptom
Alle Maschinen auf dem Host sind gleichzeitig zäh, im Gast sieht die Auslastung unauffällig aus.
Ursache
Der Host ist bei der Rechenleistung überbucht. „Hyper-V Hypervisor Logical Processor(_Total)“ liegt beim Wert „% Total Run Time“ über neunzig Prozent. Die Gäste warten auf einen freien logischen Prozessor, sehen davon aber nichts.
Lösung
Rechenleistung ergänzen oder Maschinen auf einen anderen Host verschieben. Kurzfristig hilft es, einzelne Maschinen mit vielen virtuellen Prozessoren zu verkleinern, denn eine Maschine mit acht virtuellen Prozessoren braucht acht gleichzeitig freie logische Prozessoren, um zu laufen, und wartet in einem vollen Host länger als eine mit zweien.
Symptom
Eine Maschine ist langsam, alle ihre virtuellen Prozessoren liegen dauerhaft am Anschlag.
Ursache
Die Maschine hat für ihre Last zu wenig Rechenleistung zugewiesen bekommen, oder der Host insgesamt ist überlastet und teilt ihr zu wenig zu.
Lösung
Prüf zuerst den Host. Ist er nicht überlastet, klär, ob die Anwendung mehrere Prozessoren überhaupt nutzen kann. Wenn ja, weis der Maschine weitere virtuelle Prozessoren zu. Wenn nein, ist der Weg schnellere Kerne oder eine Änderung an der Anwendung, denn zusätzliche virtuelle Prozessoren ändern bei einer Anwendung mit einem Thread nichts.
Symptom
Nur einzelne virtuelle Prozessoren der Maschine sind ausgelastet, die übrigen nicht.
Ursache
Die Last verteilt sich nicht, weil eine einzelne Queue der Engpass ist. Typisch bei Anwendungen, die viel über das Netz empfangen, oder bei solchen, die über einen einzigen virtuellen Datenträger sehr viel schreiben.
Lösung
Bei netzlastigen Anwendungen aktivierst du virtuelles Receive Side Scaling, sodass eingehender Verkehr über mehrere virtuelle Prozessoren verteilt wird. Bei speicherlastigen Anwendungen aktivierst du virtuelles NUMA und ergänzt weitere virtuelle Datenträger, damit mehrere Queues entstehen.
Symptom
Auf dem Host sind hohe Werte für „% Interrupt Time“ und „% DPC Time“ zu sehen.
Ursache
Die Verarbeitung des Netzverkehrs landet vollständig in der Stammpartition. Microsoft beschreibt genau dieses Muster: einige virtuelle Prozessoren der Stammpartition über neunzig Prozent, und die Summe aus „% Interrupt Time“ und „% DPC Time“ entspricht in etwa diesem Wert.
Lösung
Aktivier VMQ, also die Virtual Machine Queues, auf den Netzkarten. Damit verteilt die Hardware den eingehenden Verkehr direkt auf die Queues der einzelnen Maschinen, statt alles über einen Prozessor der Stammpartition zu leiten.
Symptom
Vorgänge auf dem Host und in den Maschinen dauern lange oder laufen in Zeitüberschreitungen.
Ursache
Der Datenträger ist der Engpass. Avg. Disk sec/Read beziehungsweise Avg. Disk sec/Write liegen dauerhaft über fünfzig Millisekunden, und die Queues sind entsprechend lang.
Lösung
Verteil die Maschinen über zusätzlichen Speicher, prüf schnelleren Speicher, setz gestufte Speicherplätze ein und nutz VHDX statt VHD. Wenn eine einzelne Maschine die anderen verdrängt, ist Storage QoS das passende Werkzeug: Es kennt Mindest- und Höchstwerte in normalisierten Ein- und Ausgabevorgängen, wobei alles bis 8 KB als ein Vorgang zählt und größere Anforderungen entsprechend als mehrere.
Symptom
Eine Maschine wurde über Wochen langsamer, ohne dass sich an der Last etwas geändert hat.
Ursache
Sehr häufig hängt an ihr eine Kette von Prüfpunkten. Prüfpunkte werden als AVHDX-Dateien neben der eigentlichen virtuellen Festplatte abgelegt, und jeder Lesevorgang muss die Kette durchlaufen. Dazu wächst der belegte Platz weiter, was den darunterliegenden Speicher zusätzlich belastet.
Lösung
Sieh dir die vorhandenen Prüfpunkte an und lös sie auf. Beim Löschen führt Hyper-V die AVHDX-Datei mit der VHDX-Datei zusammen und entfernt sie danach. Lösch die AVHDX-Dateien niemals von Hand. Für Sicherungszwecke sind Prüfpunkte ohnehin kein Ersatz: Ein Standardprüfpunkt hält den Arbeitsspeicherzustand fest und kann bei replizierenden Systemen zu Inkonsistenzen führen.
Die Reihenfolge der Messung
- 01 Host gesamt: liegt die gesamte Laufzeit der logischen Prozessoren über neunzig Prozent?
- 02 Maschine: liegt die gesamte Laufzeit aller virtuellen Prozessoren über neunzig Prozent, oder nur einiger?
- 03 Arbeitsspeicher: ist der verfügbare Speicher auf dem Host knapp oder nur im Gast?
- 04 Datenträger: liegen die mittleren Sekunden je Lese- oder Schreibvorgang dauerhaft über fünfzig Millisekunden?
- 05 Netz: ist die physische Karte an der Kapazitätsgrenze, oder zieht eine einzelne Maschine sehr viel?
Die vier Messungen, die zur Ursache führen
Für jede Ressource ein Zähler auf dem Host, ein Schwellenwert und eine daraus folgende Maßnahme. Der Aufwand liegt bei einer Stunde, und danach weißt du, ob du Hardware brauchst oder eine Einstellung ändern musst.
Zuerst den ganzen Host prüfen, nicht die einzelne Maschine
Der Zähler „Hyper-V Hypervisor Logical Processor(_Total)“ mit dem Wert „% Total Run Time“ zeigt, wie stark die physischen Kerne ausgelastet sind. Liegt dieser Wert über neunzig Prozent, ist der Host überlastet, und jede weitere Messung an einer einzelnen Maschine erklärt nur ein Symptom. Die Maßnahme ist dann Rechenleistung ergänzen oder Maschinen auf einen anderen Host verschieben.
Danach die virtuellen Prozessoren der betroffenen Maschine ansehen
Der Zähler „Hyper-V Hypervisor Virtual Processor“ liefert denselben Wert „% Total Run Time“ je Maschine und je virtuellem Prozessor. Liegt der Wert über neunzig Prozent für alle virtuellen Prozessoren einer Maschine, prüf zuerst, ob der Host insgesamt überlastet ist, dann, ob die Anwendung mehr Prozessoren überhaupt nutzen kann, und erst dann teilst du der Maschine weitere zu. Mehr virtuelle Prozessoren an eine Anwendung zu geben, die nur einen Thread nutzt, ändert nichts.
Ungleiche Auslastung als eigenes Muster lesen
Liegt der Wert nur bei einigen virtuellen Prozessoren über neunzig Prozent, ist das ein anderer Befund. Bei netzlastigen Anwendungen empfiehlt Microsoft in diesem Fall den Einsatz von virtuellem Receive Side Scaling. Bei speicherlastigen Anwendungen ist die Empfehlung, virtuelles NUMA zu aktivieren und weitere virtuelle Datenträger hinzuzufügen, damit sich die Last über mehrere Queues verteilt.
Beim Arbeitsspeicher auf dem Host messen
Die beiden Zähler heißen „Memory: Available MBytes“ und „Hyper-V Dynamic Memory Balancer: Available Memory“. Sind beide auf dem Host niedrig, hilft nur, nicht benötigte Dienste zu beenden und Maschinen auf einen anderen Host zu verschieben. Ist dagegen im Gast der verfügbare Arbeitsspeicher niedrig, weist du der Maschine mehr zu, und bei dynamischem Arbeitsspeicher erhöhst du den Höchstwert.
Beim Datenträger auf die Antwortzeit schauen, nicht auf den Durchsatz
Die aussagekräftigen Zähler heißen „PhysicalDisk: Avg. Disk sec/Read“ und „Avg. Disk sec/Write“, dazu die beiden Zähler für die durchschnittliche Länge der Lese- und der Schreib-Queue. Liegen die Antwortzeiten dauerhaft über fünfzig Millisekunden, ist der Speicher der Engpass. Die Maßnahmen laut Microsoft: Maschinen über zusätzlichen Speicher verteilen, schnelleren Speicher beschaffen, gestufte Speicherplätze und Storage QoS einsetzen sowie VHDX verwenden.
Beim Netz zwei Schwellen unterscheiden
Auf dem Host misst du „Network Interface: Bytes/sec“ je physischer Netzkarte. Erreicht dieser Wert neunzig Prozent der Kapazität, sind zusätzliche Netzkarten, das Verschieben von Maschinen und eine Dienstgüte für das Netz die Antwort. In der Maschine misst du „Hyper-V Virtual Network Adapter: Bytes/sec“. Ab etwa 250 Megabyte pro Sekunde empfiehlt Microsoft zusätzliche Netzwerkadapter im Team, virtuelles Receive Side Scaling und SR-IOV.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Warum die Messung im Gast in die Irre führt
Ein Gast kennt seine virtuellen Prozessoren und die Zeit, in der er auf ihnen gerechnet hat. Die Zeit, in der er auf einen freien logischen Prozessor gewartet hat, taucht in seiner Rechnung nicht auf, weil sie aus seiner Sicht schlicht nicht existiert. Genau deshalb gibt es auf dem Host eigene Zählerfamilien: eine für die logischen Prozessoren der Hardware, eine für die virtuellen Prozessoren der Gäste und eine für die virtuellen Prozessoren der Stammpartition, in der die Verwaltung läuft.
Diese drei Familien beantworten unterschiedliche Fragen. Die logischen Prozessoren sagen dir, ob die Hardware ausgelastet ist. Die virtuellen Prozessoren der Gäste sagen dir, welche Maschine tatsächlich rechnet. Die virtuellen Prozessoren der Stammpartition sagen dir, ob die Verwaltungspartition selbst zum Engpass wird, was typischerweise bei der Verarbeitung von Netzverkehr passiert. Erst alle drei zusammen ergeben ein Bild.
Für den Arbeitsspeicher gilt dasselbe Prinzip. Der verfügbare Arbeitsspeicher auf dem Host und der verfügbare Speicher des Verwalters für dynamischen Arbeitsspeicher sagen dir, ob überhaupt etwas zu verteilen ist. Der verfügbare Arbeitsspeicher im Gast sagt dir, ob die Maschine mit dem auskommt, was sie bekommen hat. Sind beide Hostwerte niedrig, hilft eine Erhöhung im Gast gar nichts, weil nichts da ist, was erhöht werden könnte.
Datenträger: Antwortzeit schlägt Durchsatz
Beim Speicher wird häufig der Durchsatz gemessen und die Antwortzeit übersehen, obwohl die Antwortzeit die Größe ist, die Nutzer spüren. Die relevanten Zähler heißen „PhysicalDisk: Avg. Disk sec/Read“ und „Avg. Disk sec/Write“, ergänzt um die durchschnittliche Länge der Lese- und der Schreib-Queue. Als Schwelle nennt Microsoft dauerhafte Werte über fünfzig Millisekunden. Dauerhaft ist dabei das entscheidende Wort: Einzelne Ausschläge während einer Sicherung sind normal.
Storage QoS ist das Werkzeug für den Fall, dass eine Maschine die anderen verdrängt. Es setzt einen Failovercluster voraus, entweder mit einem Scale-Out File Server als Speicher oder mit freigegebenen Cluster-Volumes, und arbeitet mit Richtlinien, die einen Mindest- und einen Höchstwert festlegen. Gemessen wird in normalisierten Ein- und Ausgabevorgängen: Jeder Vorgang bis 8 KB zählt als einer, größere zählen entsprechend als mehrere, eine Anforderung über 256 KB also als 32. Die Größe für die Normalisierung lässt sich clusterweit ändern, der Standardwert bleibt 8 KB.
Bei den Richtlinien gibt es zwei Formen. Eine aggregierte Richtlinie teilt die festgelegten Werte unter allen zugeordneten Datenströmen auf, alle betroffenen virtuellen Festplatten teilen sich also ein gemeinsames Budget. Eine dedizierte Richtlinie verwaltet die Werte je einzelner virtueller Festplatte. Für eine Umgebung mit vielen gleichartigen Maschinen ist die aggregierte Form der einfachere Weg, für einzelne wichtige Maschinen die dedizierte.
Prüfpunkte sind ein häufiger und leicht behebbarer Grund
Prüfpunkte werden als AVHDX-Dateien am selben Ort wie die VHDX-Dateien der Maschine abgelegt. Solange ein Prüfpunkt existiert, laufen Schreibvorgänge in die AVHDX-Datei, und Lesevorgänge müssen die Kette durchlaufen. Eine Maschine mit fünf Prüfpunkten übereinander ist deshalb spürbar langsamer als dieselbe Maschine ohne, und der belegte Platz wächst weiter, was den Speicher zusätzlich unter Druck setzt.
Das Auflösen ist einfach: Beim Löschen eines Prüfpunkts führt Hyper-V die AVHDX-Datei und die VHDX-Datei zusammen und entfernt die AVHDX-Datei anschließend. Das Zusammenführen kostet Zeit und Ein- und Ausgabeleistung, gehört also in ein ruhiges Fenster. Die Dokumentation ist an einer Stelle sehr deutlich: Lösch die AVHDX-Dateien niemals direkt im Dateisystem, denn dann ist die Kette unterbrochen und die Maschine nicht mehr lauffähig.
Grundsätzlich sind Prüfpunkte kein Sicherungsverfahren. Ein Standardprüfpunkt hält zusätzlich den Zustand des Arbeitsspeichers fest, ist aber keine vollständige Sicherung und kann bei Systemen, die Daten zwischen mehreren Knoten replizieren, zu Inkonsistenzen führen. Ein Produktionsprüfpunkt nutzt dagegen den Volumeschattenkopie-Dienst beziehungsweise unter Linux das Einfrieren des Dateisystems und erzeugt damit einen datenkonsistenten Stand ohne Momentaufnahme des Arbeitsspeichers. Produktionsprüfpunkte sind die Vorgabe, der Typ lässt sich je Maschine umstellen.
Was du nach der Messung ändern solltest und was nicht
Die häufigste Fehlreaktion auf eine langsame Maschine ist, ihr mehr virtuelle Prozessoren zu geben. Das hilft nur dann, wenn alle vorhandenen dauerhaft am Anschlag laufen und die Anwendung mehrere Threads nutzt. In allen anderen Fällen macht es die Lage schlechter, weil eine Maschine mit vielen virtuellen Prozessoren auf einem vollen Host länger darauf wartet, dass entsprechend viele logische Prozessoren gleichzeitig frei werden. Weniger ist auf einem überbuchten Host regelmäßig schneller.
Die zweithäufigste Fehlreaktion ist, den dynamischen Arbeitsspeicher abzuschalten, weil er verdächtig wirkt. Sinnvoll ist stattdessen, ihn zu messen: Wenn der verfügbare Speicher des Verwalters auf dem Host niedrig ist, ist der Host das Problem und nicht das Verfahren. Wenn im Gast der verfügbare Arbeitsspeicher knapp ist und der Host Reserven hat, erhöhst du schlicht den Höchstwert für diese Maschine.
Und die dritte Fehlreaktion ist, aus einer Momentaufnahme eine Entscheidung abzuleiten. Miss über eine Arbeitswoche, nicht über zehn Minuten, und beachte, was in dieser Zeit sonst läuft: Sicherungen, Aktualisierungen, Virenprüfungen und Deduplizierungsaufträge erzeugen genau die Werte, die man sonst als Engpass deutet. Ein Bild, das die Woche über stabil ist, trägt eine Investitionsentscheidung. Eine Messung während des Sicherungsfensters trägt gar nichts.
Dazu passende Kurse
Weil sich Leistungsindikatoren am besten an einem echten Host erschließen, sind Hyper-V-Kurse mit Schwerpunkt Leistung und Fehlersuche der schnellere Weg als das Nachlesen einzelner Zählernamen.
Wenn die Eingrenzung über die Virtualisierung hinausreicht, bis in Netz und Speicher, findest du bei cmt Kurse zur Fehlersuche in virtualisierten Umgebungen .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Danke an Trainer Sven, welcher ein sehr detailliertes und fachliches KnowHow besitzt.
Ich beziehe mich hier nur auf die Nachschlung durch Herrn Marco Jachmann. Herr Jachmann ist überaus kompetent und hat alle Inhalte professionell vermittelt.
Sehr sehr gut aufbereitete Nachschulung mit genau dem notwendigen Engagement und der erforderlichen Vorbereitung innerhalb von 48 Stunden.
Häufige Fragen
Ab welchem Verhältnis von virtuellen zu logischen Prozessoren wird es kritisch?
Sollen wir dynamischen Arbeitsspeicher überhaupt einsetzen?
Wie erkennen wir, welche Maschine die anderen ausbremst?
Bringt es etwas, Prüfpunkte regelmäßig automatisch anzulegen?
Wie viele Prüfpunkte sind je Maschine überhaupt möglich?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Windows Server-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Leistungsprobleme messen statt raten
Welche Zähler wo abgelesen werden und was sie bedeuten, lässt sich an einem laufenden Host in kurzer Zeit erarbeiten. In den Hyper-V-Kursen bei cmt gehört genau diese Eingrenzung zum Programm.
Passt dazu
- Hyper-V Failover Cluster aufbauen: Quorum, Cluster Shared Volumes, Live Migration
- Backup-Konzept für Hyper-V: Prüfpunkte sind keine Sicherung
- Hyper-V oder VMware vSphere: was für welchen Serverraum passt
- Dateiserver läuft voll: Kontingente, Dateiprüfung und Deduplizierung nutzen