Wenn Sie eine virtuelle Infrastruktur auf Basis von VMware vSphere (oder einem anderen Technologie-Stack) verwalten, hören Sie wahrscheinlich häufig Beschwerden von Benutzern: „Die virtuelle Maschine ist langsam!“ In dieser Artikelserie analysiere ich Leistungsmetriken und erkläre Ihnen, was und warum es langsamer wird und wie Sie sicherstellen können, dass es nicht langsamer wird.
Ich werde die folgenden Aspekte der Leistung virtueller Maschinen berücksichtigen:
- ZENTRALPROZESSOR,
- RAM,
- SCHEIBE,
- Netzwerk.
Ich fange mit der CPU an.
Um die Leistung zu analysieren, benötigen wir:
- vCenter-Leistungsindikatoren – Leistungsindikatoren, deren Diagramme über den vSphere-Client angezeigt 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 verwenden wir Screenshots vom C#-Client, nur weil sie im Miniaturformat besser aussehen :)
- ESXTOP – ein Dienstprogramm, das über die ESXi-Befehlszeile ausgeführt wird. Mit seiner Hilfe können Sie die Werte von Leistungsindikatoren in Echtzeit abrufen oder diese Werte für einen bestimmten Zeitraum zur weiteren Analyse in eine CSV-Datei hochladen. Als Nächstes erzähle ich Ihnen mehr über dieses Tool und stelle mehrere nützliche Links zu Dokumentationen und Artikeln zu diesem Thema bereit.
Ein bisschen Theorie
In ESXi ist ein separater Prozess – Welt in der VMware-Terminologie – für den Betrieb jeder vCPU (Virtual Machine Core) verantwortlich. Es gibt auch Serviceprozesse, die jedoch aus Sicht der Analyse der VM-Leistung weniger interessant sind.
Ein Prozess in ESXi kann einen von vier Zuständen haben:
- Führen Sie – Der Prozess leistet nützliche Arbeit.
- Wartezeit – Der Prozess führt keine Arbeit aus (im Leerlauf) oder wartet auf Ein-/Ausgabe.
- Costop – ein Zustand, der in virtuellen Maschinen mit mehreren Kernen auftritt. Es tritt auf, wenn der Hypervisor-CPU-Scheduler (ESXi-CPU-Scheduler) die gleichzeitige Ausführung aller aktiven virtuellen Maschinenkerne auf den physischen Serverkernen nicht planen kann. In der physischen Welt arbeiten alle Prozessorkerne parallel, das Gastbetriebssystem innerhalb der VM erwartet ein ähnliches Verhalten, sodass der Hypervisor die VM-Kerne verlangsamen muss, die ihren Taktzyklus schneller abschließen können. In modernen Versionen von ESXi verwendet der CPU-Scheduler einen Mechanismus namens entspanntes Co-Scheduling: Der Hypervisor berücksichtigt die Lücke zwischen dem „schnellsten“ und dem „langsamsten“ Kern der virtuellen Maschine (Skew). Wenn die Lücke einen bestimmten Schwellenwert überschreitet, wechselt der schnelle Kern in den Costop-Zustand. Wenn sich VM-Kerne längere Zeit in diesem Zustand befinden, kann dies zu Leistungsproblemen führen.
- Bereit – Der Prozess tritt in diesen Zustand ein, wenn der Hypervisor keine Ressourcen für seine Ausführung zuweisen kann. Hohe Bereitschaftswerte können zu VM-Leistungsproblemen führen.
Grundlegende CPU-Leistungsindikatoren für virtuelle Maschinen
CPU auslastung, %. Zeigt den Prozentsatz der CPU-Auslastung für einen bestimmten Zeitraum an.
Wie analysieren? Wenn eine VM die CPU dauerhaft zu 90 % auslastet oder es Spitzen bis zu 100 % gibt, dann haben wir Probleme. Probleme können sich nicht nur im „langsamen“ Betrieb der Anwendung innerhalb der VM äußern, sondern auch in der Unerreichbarkeit der VM über das Netzwerk. Wenn das Überwachungssystem anzeigt, dass die VM regelmäßig abfällt, achten Sie auf die Spitzen im CPU-Auslastungsdiagramm.
Es gibt einen Standardalarm, der die CPU-Auslastung der virtuellen Maschine anzeigt:
Was zu tun ist? Wenn die CPU-Auslastung einer VM ständig in die Höhe schnellen kann, können Sie darüber nachdenken, die Anzahl der vCPUs zu erhöhen (was leider nicht immer hilft) oder die VM auf einen Server mit leistungsstärkeren Prozessoren zu verschieben.
CPU-Auslastung in MHz
In den Diagrammen zur vCenter-Auslastung in % können Sie nur die gesamte virtuelle Maschine sehen; es gibt keine Diagramme für einzelne Kerne (in Esxtop gibt es %-Werte für Kerne). Für jeden Kern können Sie die Nutzung in MHz sehen.
Wie analysieren? Es kommt vor, dass eine Anwendung nicht für eine Multi-Core-Architektur optimiert ist: Sie nutzt nur einen Kern zu 100 % und der Rest ist ohne Last im Leerlauf. Beispielsweise startet MS SQL mit den Standardsicherungseinstellungen den Prozess nur auf einem Kern. Dadurch verlangsamt sich die Sicherung nicht aufgrund der langsamen Geschwindigkeit der Festplatten (darüber hat sich der Benutzer zunächst beschwert), sondern weil der Prozessor damit nicht zurechtkommt. Das Problem wurde durch Ändern der Parameter gelöst: Die Sicherung begann in mehreren Dateien (bzw. in mehreren Prozessen) parallel zu laufen.
Ein Beispiel für ungleichmäßige Belastung der Kerne.
Es gibt auch Situationen (wie in der Grafik oben), in denen die Kerne ungleichmäßig belastet werden und einige von ihnen Spitzenwerte von 100 % aufweisen. Wie beim Laden nur eines Kerns funktioniert der Alarm für die CPU-Auslastung nicht (er gilt für die gesamte VM), es treten jedoch Leistungsprobleme auf.
Was zu tun ist? Wenn die Software in einer virtuellen Maschine die Kerne ungleichmäßig belastet (nur einen Kern oder einen Teil der Kerne nutzt), macht es keinen Sinn, deren Anzahl zu erhöhen. In diesem Fall ist es besser, die VM auf einen Server mit leistungsstärkeren Prozessoren zu verschieben.
Sie können auch versuchen, die Stromverbrauchseinstellungen im Server-BIOS zu überprüfen. Viele Administratoren aktivieren den Hochleistungsmodus im BIOS und deaktivieren dadurch die Energiespartechnologien C-States und P-States. Moderne Intel-Prozessoren nutzen die Turbo-Boost-Technologie, die die Frequenz einzelner Prozessorkerne auf Kosten anderer Kerne erhöht. Es funktioniert jedoch nur, wenn energiesparende Technologien aktiviert sind. Wenn wir sie deaktivieren, kann der Prozessor den Stromverbrauch nicht ausgelasteter Kerne nicht reduzieren.
VMware empfiehlt, Energiespartechnologien auf Servern nicht zu deaktivieren, sondern Modi zu wählen, die die Energieverwaltung so weit wie möglich dem Hypervisor überlassen. In diesem Fall müssen Sie in den Einstellungen für den Stromverbrauch des Hypervisors die Option „Hohe Leistung“ auswählen.
Wenn Sie einzelne VMs (oder VM-Kerne) in Ihrer Infrastruktur haben, die eine erhöhte CPU-Frequenz benötigen, kann die richtige Anpassung des Stromverbrauchs deren Leistung erheblich verbessern.
CPU-bereit
Wenn sich der VM-Kern (vCPU) im Status „Bereit“ befindet, führt er keine nützliche Arbeit aus. Dieser Zustand tritt auf, wenn der Hypervisor keinen freien physischen Kern findet, dem der vCPU-Prozess der virtuellen Maschine zugewiesen werden kann.
Wie analysieren? Wenn sich die Kerne einer virtuellen Maschine mehr als 10 % der Zeit im Status „Bereit“ befinden, werden Sie normalerweise Leistungsprobleme bemerken. Einfach ausgedrückt: In mehr als 10 % der Fälle wartet die VM darauf, dass physische Ressourcen verfügbar werden.
In vCenter können Sie zwei Zähler im Zusammenhang mit CPU Ready anzeigen:
- Bereitschaft,
- Bereit.
Die Werte beider Zähler können sowohl für die gesamte VM als auch für einzelne Kerne eingesehen werden.
Die Bereitschaft zeigt den Wert sofort als Prozentsatz an, jedoch nur in Echtzeit (Daten für die letzte Stunde, Messintervall 20 Sekunden). Es ist besser, diesen Zähler nur für die Suche nach Problemen zu verwenden, die „auf den Fersen“ sind.
Fertige Zählerwerte können auch aus historischer Perspektive betrachtet werden. Dies ist nützlich, um Muster zu erkennen und das Problem tiefer zu analysieren. Wenn beispielsweise bei einer virtuellen Maschine zu einem bestimmten Zeitpunkt Leistungsprobleme auftreten, können Sie die Intervalle des CPU-Ready-Werts mit der Gesamtlast auf dem Server vergleichen, auf dem diese VM ausgeführt wird, und Maßnahmen ergreifen, um die Last zu reduzieren (falls DRS scheitert).
Im Gegensatz zur Bereitschaft wird die Bereitschaft nicht in Prozent, sondern in Millisekunden angezeigt. Dabei handelt es sich um einen Summationszähler, der angibt, wie lange sich der VM-Kern während des Messzeitraums im Bereitschaftszustand befand. Sie können diesen Wert mit einer einfachen Formel in einen Prozentsatz umrechnen:
(CPU-Bereit-Summenwert / (Standard-Aktualisierungsintervall des Diagramms in Sekunden * 1000)) * 100 = CPU-Bereitschaft %
Für die VM in der folgenden Grafik beträgt der Spitzenwert „Ready“ für die gesamte virtuelle Maschine beispielsweise wie folgt:
Bei der Berechnung des Ready-Prozentsatzes sollten Sie auf zwei Punkte achten:
- Der Ready-Wert für die gesamte VM ist die Summe der Ready-Werte aller Kerne.
- Messintervall. Bei Echtzeit beträgt sie 20 Sekunden und bei Tages-Charts beispielsweise 300 Sekunden.
Bei aktiver Fehlerbehebung können diese einfachen Punkte leicht übersehen werden und wertvolle Zeit mit der Lösung nicht vorhandener Probleme verschwendet werden.
Berechnen wir „Ready“ anhand der Daten aus der folgenden Grafik. (324474/(20*1000))*100 = 1622 % für die gesamte VM. Wenn man sich die Kerne anschaut, ist es nicht so gruselig: 1622/64 = 25 % pro Kern. In diesem Fall ist der Haken recht leicht zu erkennen: Der Ready-Wert ist unrealistisch. Wenn wir jedoch von 10–20 % für die gesamte VM mit mehreren Kernen sprechen, kann der Wert für jeden Kern im normalen Bereich liegen.
Was zu tun ist? Ein hoher Bereitschaftswert weist darauf hin, dass der Server nicht über genügend Prozessorressourcen für den normalen Betrieb virtueller Maschinen verfügt. In einer solchen Situation bleibt nur noch die Reduzierung der Überbelegung pro Prozessor (vCPU:pCPU). Dies kann natürlich durch eine Reduzierung der Parameter vorhandener VMs oder durch die Migration eines Teils der VMs auf andere Server erreicht werden.
Co-Stopp
Wie analysieren? Dieser Zähler ist ebenfalls vom Typ „Summation“ und wird auf die gleiche Weise wie „Bereit“ in Prozentwerte umgewandelt:
(CPU-Co-Stop-Summenwert / (Standard-Aktualisierungsintervall des Diagramms in Sekunden * 1000)) * 100 = CPU-Co-Stop %
Dabei ist auch auf die Anzahl der Kerne auf der VM und das Messintervall zu achten.
Im Costop-Zustand führt der Kernel keine nützliche Arbeit aus. Bei richtiger Auswahl der VM-Größe und normaler Auslastung des Servers sollte der Co-Stop-Zähler nahe Null liegen.
In diesem Fall ist die Belastung eindeutig abnormal :)
Was zu tun ist? Wenn mehrere VMs mit einer großen Anzahl an Kernen auf einem Hypervisor laufen und es zu einer Überbelegung der CPU kommt, kann es zu einem Anstieg des Co-Stop-Zählers kommen, was zu Problemen mit der Leistung dieser VMs führt.
Außerdem erhöht sich der Co-Stop, wenn die aktiven Kerne einer VM Threads auf einem physischen Serverkern mit aktiviertem Hyper-Treading verwenden. Diese Situation kann beispielsweise auftreten, wenn die VM über mehr Kerne verfügt, als physisch auf dem Server verfügbar sind, auf dem sie ausgeführt wird, oder wenn die Einstellung „preferHT“ für die VM aktiviert ist. Sie können mehr über diese Einstellung erfahren .
Um Probleme mit der VM-Leistung aufgrund eines hohen Co-Stops zu vermeiden, wählen Sie die VM-Größe entsprechend den Empfehlungen des Herstellers der Software, die auf dieser VM ausgeführt wird, und den Fähigkeiten des physischen Servers aus, auf dem die VM ausgeführt wird.
Fügen Sie keine Kerne in Reserve hinzu; dies kann zu Leistungsproblemen nicht nur für die VM selbst, sondern auch für ihre Nachbarn auf dem Server führen.
Weitere nützliche CPU-Metriken
Führen Sie – Wie viel Zeit (ms) während des Messzeitraums war die vCPU im RUN-Zustand, d. h. sie hat tatsächlich nützliche Arbeit geleistet.
Leerlauf – wie lange (ms) während des Messzeitraums die vCPU im Zustand der Inaktivität war. Hohe Idle-Werte sind kein Problem, die vCPU hatte einfach „nichts zu tun“.
Wartezeit – wie lange (ms) während des Messzeitraums die vCPU im Wartezustand war. Da IDLE in diesem Zähler enthalten ist, weisen hohe Wait-Werte ebenfalls nicht auf ein Problem hin. Wenn Wait IDLE jedoch niedrig ist, während Wait hoch ist, bedeutet dies, dass die VM auf den Abschluss von E/A-Vorgängen gewartet hat, was wiederum auf ein Problem mit der Leistung der Festplatte oder virtueller Geräte der VM hinweisen kann.
Maximal begrenzt – wie lange (ms) während des Messzeitraums die vCPU aufgrund des eingestellten Ressourcenlimits im Bereitschaftszustand war. Wenn die Leistung aus unerklärlichen Gründen niedrig ist, ist es sinnvoll, den Wert dieses Zählers und das CPU-Limit in den VM-Einstellungen zu überprüfen. VMs können tatsächlich Grenzen haben, die Ihnen nicht bekannt sind. Dies geschieht beispielsweise, wenn eine VM aus einer Vorlage geklont wurde, für die das CPU-Limit festgelegt wurde.
Tausch, warte – wie lange während des Messzeitraums die vCPU auf einen Vorgang mit VMkernel Swap gewartet hat. Liegen die Werte dieses Zählers über Null, dann hat die VM definitiv Leistungsprobleme. Wir werden im Artikel über RAM-Zähler mehr über SWAP sprechen.
ESXTOP
Wenn sich Leistungsindikatoren in vCenter gut für die Analyse historischer Daten eignen, sollte die operative Analyse des Problems besser in ESXTOP durchgeführt werden. Hier werden alle Werte in vorgefertigter Form dargestellt (keine Übersetzung erforderlich) und die minimale Messdauer beträgt 2 Sekunden.
Der ESXTOP-Bildschirm für CPU wird mit der „c“-Taste aufgerufen und sieht so aus:
Der Einfachheit halber können Sie nur virtuelle Maschinenprozesse verlassen, indem Sie Umschalt-V drücken.
Um Metriken für einzelne VM-Kerne anzuzeigen, drücken Sie „e“ und geben Sie die GID der gewünschten VM ein (30919 im Screenshot unten):
Lassen Sie mich kurz auf die standardmäßig angezeigten Spalten eingehen. Durch Drücken von „f“ können weitere Spalten hinzugefügt werden.
NWLD (Anzahl der Welten) – Anzahl der Prozesse in der Gruppe. Um die Gruppe zu erweitern und Metriken für jeden Prozess anzuzeigen (z. B. für jeden Kern in einer Multi-Core-VM), drücken Sie „e“. Wenn es mehr als einen Prozess in einer Gruppe gibt, dann sind die Metrikwerte für die Gruppe gleich der Summe der Metriken für die einzelnen Prozesse.
%GEBRAUCHT – wie viele Server-CPU-Zyklen von einem Prozess oder einer Gruppe von Prozessen verwendet werden.
%LAUFEN – wie lange während des Messzeitraums der Prozess im RUN-Zustand war, d. h. hat nützliche Arbeit geleistet. Der Unterschied zu %USED besteht darin, dass Hyper-Threading, Frequenzskalierung und Zeitaufwand für Systemaufgaben (%SYS) nicht berücksichtigt werden.
%SYS – Zeit, die für Systemaufgaben aufgewendet wird, zum Beispiel: Interrupt-Verarbeitung, E/A, Netzwerkbetrieb usw. Der Wert kann hoch sein, wenn die VM über große E/A verfügt.
%OVRLP – wie viel Zeit der physische Kern, auf dem der VM-Prozess läuft, für Aufgaben anderer Prozesse aufgewendet hat.
Diese Kennzahlen beziehen sich wie folgt aufeinander:
%USED = %RUN + %SYS - %OVRLP.
Typischerweise ist die %USED-Metrik aussagekräftiger.
%WARTEN – wie lange während des Messzeitraums der Prozess im Wartezustand war. Aktiviert IDLE.
%LEERLAUF – wie lange während des Messzeitraums der Prozess im IDLE-Zustand war.
%SWPWT – wie lange während des Messzeitraums die vCPU auf einen Vorgang mit VMkernel Swap gewartet hat.
%VMWAIT – Wie lange während des Messzeitraums war die vCPU im Zustand des Wartens auf ein Ereignis (normalerweise E/A). In vCenter gibt es keinen ähnlichen Zähler. Hohe Werte weisen auf Probleme mit I/O auf der VM hin.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Wenn die VM keinen VMkernel Swap verwendet, empfiehlt es sich bei der Analyse von Leistungsproblemen, auf %VMWAIT zu achten, da diese Metrik die Zeit, in der die VM nichts tat (%IDLE), nicht berücksichtigt.
%RDY – wie lange während des Messzeitraums der Prozess im Bereitschaftszustand war.
%CSTP – wie lange während des Messzeitraums der Prozess im Costop-Zustand war.
%MLMTD – wie lange während des Messzeitraums die vCPU aufgrund des eingestellten Ressourcenlimits im Bereitschaftszustand war.
%WAIT + %RDY + %CSTP + %RUN = 100 % – der VM-Kern befindet sich immer in einem dieser vier Zustände.
CPU auf Hypervisor
vCenter verfügt auch über CPU-Leistungsindikatoren für den Hypervisor, diese sind jedoch nicht interessant – sie sind einfach die Summe der Zähler für alle VMs auf dem Server.
Die bequemste Möglichkeit, den CPU-Status auf dem Server anzuzeigen, ist die Registerkarte „Übersicht“:
Sowohl für den Server als auch für die virtuelle Maschine gibt es einen Standard-Alarm:
Wenn die CPU-Auslastung des Servers hoch ist, kommt es bei den darauf ausgeführten VMs zu Leistungsproblemen.
In ESXTOP werden die CPU-Auslastungsdaten des Servers oben auf dem Bildschirm angezeigt. Neben der Standard-CPU-Auslastung, die für Hypervisoren wenig aussagekräftig ist, gibt es noch drei weitere Metriken:
KERNNUTZUNG (%) – Laden des physischen Serverkerns. Dieser Zähler zeigt an, wie viel Zeit der Kern während des Messzeitraums Arbeit geleistet hat.
PCPU-NUTZUNG (%) – Wenn Hyper-Threading aktiviert ist, gibt es zwei Threads (PCPU) pro physischem Kern. Diese Metrik zeigt, wie lange jeder Thread brauchte, um die Arbeit abzuschließen.
PCPU VERWENDET (%) – das Gleiche wie PCPU UTIL(%), berücksichtigt jedoch Frequenzskalierung (entweder Reduzierung der Kernfrequenz zur Energieeinsparung oder Erhöhung der Kernfrequenz aufgrund der Turbo-Boost-Technologie) und Hyper-Threading.
PCPU_USED% = PCPU_UTIL% * effektive Kernfrequenz / nominale Kernfrequenz.
In diesem Screenshot ist der USED-Wert aufgrund von Turbo Boost für einige Kerne größer als 100 %, da die Kernfrequenz höher als die Nennfrequenz ist.
Ein paar Worte zur Berücksichtigung von Hyper-Threading. Wenn Prozesse zu 100 % der Zeit auf beiden Threads des physischen Kerns des Servers ausgeführt werden, während der Kern mit der Nennfrequenz arbeitet, dann:
- CORE UTIL für den Kern beträgt 100 %,
- PCPU UTIL für beide Threads beträgt 100 %,
- PCPU USED für beide Threads beträgt 50 %.
Wenn beide Threads während des Messzeitraums nicht 100 % der Zeit funktionierten, wird in den Zeiträumen, in denen die Threads parallel arbeiteten, die für die Kerne verwendete PCPU halbiert.
ESXTOP verfügt außerdem über einen Bildschirm mit Parametern zum Stromverbrauch der Server-CPU. Hier können Sie sehen, ob der Server energiesparende Technologien verwendet: C-States und P-States. Mit der „p“-Taste aufgerufen:
Häufige Probleme mit der CPU-Leistung
Abschließend gehe ich auf die typischen Ursachen von Problemen mit der VM-CPU-Leistung ein und gebe kurze Tipps zu deren Behebung:
Die Kerntaktrate reicht nicht aus. Wenn es nicht möglich ist, Ihre VM auf leistungsstärkere Kerne zu aktualisieren, können Sie versuchen, die Energieeinstellungen zu ändern, damit Turbo Boost effizienter arbeitet.
Falsche VM-Größe (zu viele/wenige Kerne). Wenn Sie wenige Kerne installieren, kommt es zu einer hohen CPU-Last auf der VM. Wenn es viele gibt, fangen Sie einen hohen Co-Stop ein.
Große Überbelegung der CPU auf dem Server. Wenn die VM eine hohe Bereitschaft aufweist, reduzieren Sie die CPU-Überbelegung.
Falsche NUMA-Topologie auf großen VMs. Die von der VM erkannte NUMA-Topologie (vNUMA) muss mit der NUMA-Topologie des Servers (pNUMA) übereinstimmen. Diagnosen und mögliche Lösungen für dieses Problem sind beispielsweise im Buch beschrieben . Wenn Sie nicht tiefer gehen möchten und keine Lizenzbeschränkungen für das auf der VM installierte Betriebssystem haben, erstellen Sie viele virtuelle Sockets auf der VM, einen Kern nach dem anderen. Du wirst nicht viel verlieren :)
Das ist für mich alles bezüglich der CPU. Fragen stellen. Im nächsten Teil werde ich über RAM sprechen.
Nützliche Links
Source: habr.com