Leistungsanalyse von virtuellen Maschinen in VMware vSphere. Teil 1: CPU

Wenn Sie virtuelle Infrastrukturen auf Basis von VMware vSphere (oder einem anderen Technologie-Stack) verwalten, hören Sie möglicherweise häufig von Nutzern die Beschwerden: "Die virtuelle Maschine läuft langsam!" In dieser Artikelreihe werde ich Leistungskennzahlen untersuchen und erläutern, was und warum es „stockt“ und wie man dafür sorgt, dass es nicht „stockt“.

Ich werde folgende Aspekte der Leistung virtueller Maschinen betrachten:

• CPU,
• RAM,
• DISK,
• Netzwerk.

Ich beginne mit der CPU.

Für die Leistungsanalyse benötigen wir:

• vCenter Leistungszähler – Leistungszähler, deren Grafiken über den vSphere Client eingesehen werden können. Informationen zu diesen Zählern sind in jeder Version des Clients verfügbar ("dicker" Client in C#, Web-Client in Flex und Web-Client in HTML5). In diesen Artikeln werden wir Screenshots aus dem C#-Client verwenden, einfach weil sie in der Miniaturansicht besser aussehen :)
• ESXTOP – Ein Tool, das aus der Kommandozeile von ESXi gestartet wird. Damit können Sie in Echtzeit Leistungszählerwerte abrufen oder diese für einen bestimmten Zeitraum in eine .csv-Datei exportieren, um sie anschließend zu analysieren. Ich werde dieses Werkzeug im Folgenden genauer vorstellen und einige nützliche Links zur Dokumentation und zu thematischen Artikeln bereitstellen.

Ein wenig Theorie

In ESXi ist jeder vCPU (Kern der virtuellen Maschine) für einen separaten Prozess verantwortlich – in der VMware-Terminologie als 'world' bezeichnet. Es gibt auch Systemprozesse, aber aus der Perspektive der Leistungsanalyse von VMs sind diese weniger interessant.

Ein Prozess in ESXi kann sich in einem von vier Zuständen befinden:

• Ausführen – Der Prozess führt eine nützliche Arbeit aus.
• Warten – Der Prozess führt keine Arbeit aus (idle) oder wartet auf Eingabe/Ausgabe.
• Costop – ein Zustand, der in mehrkernigen virtuellen Maschinen auftritt. Er entsteht, wenn der CPU-Planer des Hypervisors (ESXi CPU Scheduler) nicht die gleichzeitige Ausführung aller aktiven Kerne der virtuellen Maschine auf den physischen Kernen des Servers planen kann. In der physischen Welt arbeiten alle Prozessorkerne parallel, das Gastbetriebssystem innerhalb der VM rechnet mit einem ähnlichen Verhalten, weshalb der Hypervisor gezwungen ist, die Kerne der VM zu drosseln, die die Möglichkeit haben, ihren Takt schneller zu beenden. In modernen Versionen von ESXi verwendet der CPU-Planer einen Mechanismus, der als relaxed co-scheduling bezeichnet wird: Der Hypervisor bewertet den Unterschied zwischen dem "schnellsten" und dem "langsamsten" Kern der virtuellen Maschine (skew). Überschreitet dieser Unterschied einen bestimmten Schwellenwert, wechselt der "schnelle" Kern in den Zustand costop. Verbringen die Kerne der VM viel Zeit in diesem Zustand, kann dies Leistungsprobleme verursachen.
• Bereit – ein Prozess wechselt in diesen Zustand, wenn der Hypervisor nicht in der Lage ist, Ressourcen für seine Ausführung bereitzustellen. Hohe Werte für ready können Leistungsprobleme der VM verursachen.

Hauptleistungsmesswerte für die CPU der virtuellen Maschine

CPU-Nutzung, %. Zeigt den prozentualen CPU-Verbrauch über einen bestimmten Zeitraum an.

Wie analysiert man das? Wenn die VM stabil 90 % CPU nutzt oder es gelegentlich zu Spitzen von 100 % kommt, haben wir ein Problem. Die Probleme können sich nicht nur in einer "langsamen" Anwendung innerhalb der VM äußern, sondern auch in der Nichterreichbarkeit der VM über das Netzwerk. Wenn das Überwachungssystem anzeigt, dass die VM gelegentlich ausfällt, achten Sie auf die Spitzen im CPU-Nutzungsdiagramm.

Es gibt einen Standardalarm, der die CPU-Auslastung der virtuellen Maschine anzeigt:

Was tun? Wenn die CPU-Nutzung bei der VM ständig hoch ist, sollten Sie in Erwägung ziehen, die Anzahl der vCPUs zu erhöhen (leider hilft das nicht immer) oder die VM auf einen Server mit leistungsstärkeren Prozessoren zu migrieren.

CPU-Nutzung in MHz

In den Diagrammen im vCenter kann man die Nutzung in % nur für die gesamte virtuelle Maschine einsehen; Diagramme für einzelne Kerne sind nicht verfügbar (in Esxtop sind die Werte in % nach Kernen vorhanden). Für jeden Kern kann die Nutzung in MHz angezeigt werden.

Wie analysiert man das? Es kann vorkommen, dass eine Anwendung nicht für eine Multi-Core-Architektur optimiert ist: Sie verwendet nur ein Kern zu 100 %, während die anderen ungenutzt bleiben. Zum Beispiel startet MS SQL bei den Standard-Backup-Einstellungen den Prozess nur auf einem Kern. Das Backup wird nicht durch langsame Festplattengeschwindigkeiten (woran der Benutzer ursprünglich beschwert hat) verlangsamt, sondern weil die CPU überlastet ist. Das Problem wurde durch eine Änderung der Einstellungen behoben: Das Backup wird nun parallel in mehreren Dateien (und entsprechend in mehreren Prozessen) gestartet.

Beispiel für eine ungleichmäßige Belastung der Kerne.

Es kommt auch vor, dass (wie im obigen Diagramm) die Kerne ungleichmäßig belastet sind und einige von ihnen Spitzen von 100 % haben. Ähnlich wie bei der Belastung eines einzelnen Kerns wird der Alarm für die CPU-Nutzung nicht ausgelöst (er wirkt sich auf die gesamte VM aus), aber die Leistungsprobleme werden bestehen bleiben.

Was tun? Wenn die Software in der virtuellen Maschine die Kerne ungleichmäßig belastet (nur ein Kern oder einige Kerne nutzt), macht es keinen Sinn, die Anzahl der Kerne zu erhöhen. In diesem Fall ist es besser, die VM auf einen Server mit leistungsstärkeren Prozessoren zu verschieben.

Es kann auch sinnvoll sein, die Energieeinstellungen im BIOS des Servers zu überprüfen. Viele Administratoren aktivieren im BIOS den Modus "Höchstleistung" und deaktivieren damit die Energiespartechnologien C-Stufen und P-Stufen. In modernen Intel-Prozessoren wird die Technologie Turbo Boost verwendet, die die Frequenz einzelner Prozessorkerne auf Kosten anderer Kerne erhöht. Diese funktioniert jedoch nur, wenn Energiespartechnologien aktiviert sind. Wenn wir diese deaktivieren, kann der Prozessor den Energieverbrauch der nicht belasteten Kerne nicht reduzieren.

VMware empfiehlt, die Energiespartechnologien auf Servern nicht zu deaktivieren, sondern Modi zu wählen, die dem Hypervisor die maximale Kontrolle über das Energiemanagement überlassen. Dabei sollte im Energiemanagement des Hypervisors der Modus "Höchstleistung" ausgewählt werden.

Wenn in Ihrer Infrastruktur einzelne VMs (oder VMs-Kerne) eine höhere CPU-Frequenz benötigen, kann eine korrekte Energiekonfiguration ihre Leistung erheblich verbessern.

CPU Ready (Bereitschaft)

Wenn der vCPU-Kern einer virtuellen Maschine im Zustand 'Ready' ist, leistet er keine nützliche Arbeit. Dieser Zustand tritt auf, wenn der Hypervisor keinen freien physischen Kern findet, auf den der vCPU-Prozess der virtuellen Maschine zugewiesen werden kann.

Wie analysiert man das? In der Regel, wenn die Kerne der virtuellen Maschine mehr als 10% der Zeit im Zustand 'Ready' sind, werden Sie Leistungsprobleme bemerken. Einfach ausgedrückt, wartet die VM mehr als 10% der Zeit auf die Verfügbarkeit physischer Ressourcen.

In vCenter können Sie zwei Zähler in Bezug auf CPU Ready einsehen:

• Readiness,
• Ready.

Die Werte beider Zähler können sowohl für die gesamte VM als auch für einzelne Kerne angezeigt werden.
Readiness zeigt den Wert sofort in Prozent an, jedoch nur in Echtzeit (Daten der letzten Stunde, Messintervall 20 Sekunden). Dieser Zähler sollte am besten nur zur Erkennung von Problemen 'in Echtzeit' verwendet werden.

Die Werte des Ready-Zählers können auch historisch betrachtet werden. Dies ist hilfreich, um Muster zu identifizieren und eine tiefere Analyse des Problems durchzuführen. Wenn beispielsweise eine virtuelle Maschine zu einem bestimmten Zeitpunkt Leistungsprobleme hat, kann man die Zeiträume mit erhöhtem CPU Ready-Wert mit der Gesamtlast des Servers, auf dem die VM läuft, abgleichen und Maßnahmen zur Reduzierung der Last ergreifen (falls DRS nicht funktioniert hat).

Im Gegensatz zu Readiness wird Ready nicht in Prozent, sondern in Millisekunden angezeigt. Dies ist ein Summationszähler, das heißt, er zeigt an, wie viel Zeit die VM-Kerne im Messzeitraum im Zustand Ready waren. Um diesen Wert in Prozent umzurechnen, kann die folgende einfache Formel verwendet werden:

(CPU Ready Summationswert / (Standard-Updateintervall der Grafik in Sekunden * 1000)) * 100 = CPU Ready %

Beispielsweise ergibt sich für die VM im untenstehenden Diagramm der maximale Ready-Wert für die gesamte virtuelle Maschine wie folgt:

Bei der Berechnung des Ready-Wertes in Prozent sollte auf zwei Punkte geachtet werden:

• Der Ready-Wert für die gesamte VM ist die Summe der Ready-Werte der Kerne.
• Messintervall. Für Echtzeitmessungen beträgt dies 20 Sekunden, während es bei Tagesdiagrammen beispielsweise 300 Sekunden beträgt.

Bei aktivem Troubleshooting können diese einfachen Punkte leicht übersehen werden, was wertvolle Zeit für die Lösung nicht vorhandener Probleme kostet.

Wir berechnen Ready basierend auf den Daten aus dem untenstehenden Diagramm. (324474/(20*1000))*100 = 1622% für die gesamte VM. Wenn man die Kerne betrachtet, sieht es bereits nicht so schlimm aus: 1622/64 = 25% pro Kern. In diesem Fall ist es recht einfach, einen Haken zu entdecken: Der Wert für Ready ist unrealistisch. Aber wenn es um 10-20% für die gesamte VM mit mehreren Kernen geht, könnte der Wert pro Kern im Normbereich liegen.

Was tun? Ein hoher Ready-Wert weist darauf hin, dass dem Server die CPU-Ressourcen für den ordnungsgemäßen Betrieb der virtuellen Maschinen fehlen. In dieser Situation bleibt nur, die Überbuchung der CPU (vCPU:pCPU) zu reduzieren. Offensichtlich kann dies erreicht werden, indem die Parameter bestehender VMs verringert oder ein Teil der VMs auf andere Server migriert wird.

Co-stop

Wie analysiert man das? Dieser Zähler ist ebenfalls vom Typ Summation und wird ähnlich wie Ready in Prozent umgerechnet:

(CPU co-stop Summationswert / (Standardaktualisierungsintervall des Diagramms in Sekunden * 1000)) * 100 = CPU co-stop %

Hier sollte ebenfalls auf die Anzahl der Kerne in der VM und das Messintervall geachtet werden.
Im Zustand von co-stop führt der Kern keine nützliche Arbeit aus. Bei passender VM-Größe und normaler Serverlast sollte der co-stop-Zähler nahe Null liegen.

In diesem Fall ist die Last eindeutig abnormal :)

Was tun? Wenn mehrere VMs mit vielen Kernen auf einem Hypervisor laufen und eine CPU-Überschreitung vorliegt, kann der co-stop-Zähler steigen, was zu Leistungsproblemen dieser VMs führen kann.

Der co-stop-Wert wird auch steigen, wenn aktive Kerne einer VM Threads auf einem physikalischen Kern des Servers mit aktiviertem Hyper-Threading verwenden. Solch eine Situation kann beispielsweise auftreten, wenn die VM mehr Kerne besitzt, als physikalisch auf dem Server vorhanden sind, oder wenn für die VM die Einstellung „preferHT“ aktiviert ist. Weitere Informationen zu dieser Einstellung finden Sie hier. hier.

Um Leistungsprobleme bei VMs aufgrund eines hohen co-stop-Werts zu vermeiden, wählen Sie die VM-Größe gemäß den Empfehlungen des Softwareherstellers, der auf dieser VM läuft, und den Möglichkeiten des physikalischen Servers, auf dem die VM arbeitet.

Fügen Sie keine Kerne vorsorglich hinzu, da dies nicht nur die Leistung der VM selbst, sondern auch ihrer Nachbarn auf dem Server beeinträchtigen kann.

Weitere nützliche CPU-Metriken

Ausführen – wie viel Zeit (ms) der vCPU während des Messzeitraums im Zustand RUN war, das heißt, aktiv nützliche Arbeit verrichtet hat.

Idle – wie viel Zeit (ms) der vCPU während des Messzeitraums im Leerlauf war. Hohe Idle-Werte sind kein Problem, da der vCPU einfach 'nichts zu tun' hatte.

Warten – wie viel Zeit (ms) der vCPU während des Messzeitraums im Wartezustand war. Da in diesen Zähler IDLE einbezogen wird, bedeuten hohe Wait-Werte ebenfalls nicht, dass ein Problem vorliegt. Wenn jedoch bei hohem Wait der IDLE-Wert niedrig ist, bedeutet das, dass die VM auf den Abschluss von E/A-Operationen gewartet hat, was auf mögliche Probleme mit der Festplattenleistung oder bestimmten virtuellen Geräten der VM hindeuten kann.

Maximal begrenzt – wie viel Zeit (ms) der vCPU während des Messzeitraums im Zustand Ready aufgrund einer festgelegten Ressourcengrenze war. Wenn die Leistung unerklärlich niedrig ist, kann es hilfreich sein, diesen Zählerwert und das CPU-Limit in den VM-Einstellungen zu überprüfen. Es könnte tatsächlich Limits für die VM geben, von denen Sie nichts wissen. Dies passiert beispielsweise, wenn die VM aus einer Vorlage geklont wurde, auf der ein CPU-Limit festgelegt war.

Swap-Wartezeit – wie lange während des Messzeitraums vCPU auf eine Operation mit VMkernel Swap gewartet wurde. Wenn die Werte dieses Zählers über null liegen, hat die VM definitiv Leistungsprobleme. Mehr über SWAP erfahren Sie in unserem Artikel über Speicherkontrolle.

ESXTOP

Während die Leistungszähler in vCenter gut zur Analyse historischer Daten sind, eignet sich die Analyse von Problemen in ESXTOP besser. Hier werden alle Werte in vorgefertigter Form angezeigt (Nichts muss übersetzt werden), und der minimale Messzeitraum beträgt 2 Sekunden.
Der ESXTOP-Bildschirm für CPU wird mit der Taste „c“ aufgerufen und sieht folgendermaßen aus:

Zur Vereinfachung können Sie nur die Prozesse der virtuellen Maschinen anzeigen, indem Sie Shift-V drücken.
Um Metriken zu einzelnen Kernen der VM anzuzeigen, drücken Sie „e“ und geben Sie die GID der gewünschten VM ein (30919 im Screenshot unten):

Ich werde kurz die Spalten durchgehen, die standardmäßig angezeigt werden. Zusätzliche Spalten können hinzugefügt werden, indem Sie „f“ drücken.

NWLD (Anzahl der Welten) – die Anzahl der Prozesse in der Gruppe. Um die Gruppe zu erweitern und die Metriken für jeden Prozess (z. B. für jedes Kern einer Mehrkern-VM) zu sehen, drücken Sie „e“. Wenn in der Gruppe mehr als ein Prozess vorhanden ist, sind die Metrikwerte für die Gruppe die Summe der Werte für die einzelnen Prozesse.

%VERWENDET – wie viele CPU-Zyklen der Server von einem Prozess oder einer Gruppe von Prozessen verwendet.

%LAUFEN – wie lange der Prozess im Messzeitraum im Zustand RUN war, d. h. nützliche Arbeit geleistet hat. Unterscheidet sich von %VERWENDET durch die Nichterfassung von Hyper-Threading, Frequenzskalierung und der Zeit, die für Systemaufgaben aufgewendet wurde (%SYS).

%SYS – die Zeit, die für Systemaufgaben aufgewendet wurde, z. B.: Interrupt-Verarbeitung, E/A, Netzwerkbetrieb usw. Der Wert kann hoch sein, wenn die VM einen hohen E/A-Wert hat.

%ÜBERLAPPT – wie viel Zeit das physische Kern, auf dem der VM-Prozess läuft, mit Aufgaben anderer Prozesse verbracht hat.

Diese Metriken stehen in folgender Beziehung zueinander:

%VERWENDET = %LAUFEN + %SYS — %ÜBERLAPPT.

In der Regel ist die Metrik %VERWENDET informativer.

%WARTEN – wie lange der Prozess im Messzeitraum im Zustand Warte war. Beinhaltet IDLE.

%IDLE – wie viel Zeit der Prozess im Messzeitraum im Zustand IDLE war.

%SWPWT – wie viel Zeit der vCPU im Messzeitraum auf eine Operation mit dem VMkernel Swap gewartet hat.

%VMWAIT – wie viel Zeit der vCPU im Messzeitraum im Wartezustand für Ereignisse verbracht hat (normalerweise Ein-/Ausgaben). Ein ähnlicher Zähler existiert nicht in vCenter. Hohe Werte deuten auf Probleme mit Ein-/Ausgaben auf der VM hin.

%WAIT = %VMWAIT + %IDLE + %SWPWT.

Wenn die VM keinen VMkernel Swap verwendet, ist es sinnvoll, bei der Analyse von Leistungsproblemen auf %VMWAIT zu achten, da diese Kennzahl die Zeit, in der die VM nichts getan hat (%IDLE), nicht berücksichtigt.

%RDY – wie viel Zeit der Prozess im Messzeitraum im Zustand Ready war.

%CSTP – wie viel Zeit der Prozess im Messzeitraum im Zustand costop war.

%MLMTD – wie viel Zeit der vCPU im Messzeitraum im Zustand Ready aufgrund einer festgelegten Ressourcenobergrenze war.

%WAIT + %RDY + %CSTP + %RUN = 100% – der VM-Kern befindet sich ständig in einem dieser vier Zustände.

CPU auf dem Hypervisor

In vCenter gibt es auch Leistungsmessgrößen für die CPU des Hypervisors, aber diese bieten nichts Interessantes – es handelt sich einfach um die Summe der Zähler aller VMs auf dem Server.
Am einfachsten lässt sich der Zustand der CPU auf dem Server auf der Registerkarte Zusammenfassung beobachten.

Für den Server, wie auch für die virtuelle Maschine, gibt es einen Standardalarm:

Bei hoher Auslastung der CPU des Servers treten bei den darauf laufenden virtuellen Maschinen Leistungsprobleme auf.

In ESXTOP werden die Daten zur CPU-Auslastung des Servers oben auf dem Bildschirm angezeigt. Neben der standardmäßigen CPU-Auslastung, die für Hypervisoren wenig aussagekräftig ist, gibt es noch drei weitere Metriken:

CORE UTIL(%) – die Auslastung des physikalischen Serverkerns. Dieser Zähler zeigt an, wie viel Zeit der Kern während des Messzeitraums mit Arbeit verbracht hat.

PCPU UTIL(%) – wenn Hyper-Threading aktiviert ist, hat jeder physikalische Kern zwei Threads (PCPU). Diese Metrik zeigt an, wie viel Zeit jeder Thread mit Arbeit beschäftigt war.

PCPU USED(%) – das Gleiche wie PCPU UTIL(%), berücksichtigt jedoch die Frequenzanpassung (entweder die Reduzierung der Kernen Frequenz zur Energieeinsparung oder die Erhöhung der Frequenz durch die Turbo Boost-Technologie) und das Hyper-Threading.

PCPU_USED% = PCPU_UTIL% * effektive Kernfrequenz / nominale Kernfrequenz.

Auf diesem Screenshot liegt der Wert für einige Kerne aufgrund der Turbo Boost-Technologie über 100%, da die Kernfrequenz höher als die nominale ist.

Ein paar Worte dazu, wie Hyper-Threading berücksichtigt wird. Wenn Prozesse zu 100 % der Zeit auf beiden Threads eines physischen Serverkerns ausgeführt werden und der Kern mit seiner nominalen Frequenz arbeitet, dann:

• CORE UTIL für den Kern wird 100 % sein,
• PCPU UTIL für beide Threads wird 100 % betragen,
• PCPU USED für beide Threads wird 50 % sein.

Wenn beide Threads in der Messperiode nicht 100 % der Zeit aktiv waren, wird PCPU USED für die Kerne in den Zeiträumen, in denen die Threads parallel arbeiteten, halbiert.

In ESXTOP gibt es auch einen Bildschirm mit den Energieverbrauchsparametern des Servers. Hier kann man sehen, ob der Server Energiespartechnologien wie C-Staaten und P-Staaten nutzt. Aufgerufen durch die Taste „p“:

Typische CPU-Leistungsprobleme

Zum Abschluss möchte ich auf häufige Ursachen für CPU-Leistungsprobleme von VMs eingehen und einige kurze Tipps zu deren Lösung geben:

Es fehlt an der Taktfrequenz des Kerns. Wenn es nicht möglich ist, die VM auf leistungsstärkere Kerne zu migrieren, können die Einstellungen für die Energieverwaltung geändert werden, damit der Turbo Boost effektiver arbeitet.

Falsches Sizing der VM (zu viele/wenige Kerne). Wenn zu wenige Kerne zugewiesen werden, liegt eine hohe Auslastung der CPU der VM vor. Bei zu vielen Kerne ergibt sich eine hohe Co-Stop.

Hohe CPU-Überbuchung auf dem Server. Wenn die VM eine hohe Bereitschaft aufweist, reduzieren Sie die CPU-Überbuchung.

Falsche NUMA-Topologie auf großen VMs. Die NUMA-Topologie, die die VM sieht (vNUMA), muss mit der NUMA-Topologie des Servers (pNUMA) übereinstimmen. Informationen zur Diagnose und mögliche Lösungsansätze sind beispielsweise im Buch „VMware vSphere 6.5 Host Resources Deep Dive“. Wenn Sie sich nicht vertiefen möchten und keine Lizenzbeschränkungen für das auf der VM installierte Betriebssystem haben, verwenden Sie auf der VM viele virtuelle Sockets mit einem Kern. Sie verlieren nicht viel 🙂

Das wäre alles zur CPU. Stellen Sie Fragen. Im nächsten Teil werde ich über den Arbeitsspeicher sprechen.

Nützliche Linkshttp://virtual-red-dot.info/vm-cpu-counters-vsphere/
https://kb.vmware.com/kb/1017926
http://www.yellow-bricks.com/2012/07/17/why-is-wait-so-high/
https://communities.vmware.com/docs/DOC-9279
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/whats-new-vsphere65-perf.pdf
https://pages.rubrik.com/host-resources-deep-dive_request.html

Quelle: habr.com