In diesem Artikel sprechen wir über die Leistungsmessungen des Arbeitsspeichers (RAM) in vSphere.
Bei der Arbeitsspeicher-Leistung scheint alles eindeutiger zu sein als bei der CPU: Wenn es bei einer VM zu Leistungsproblemen kommt, kann man dies kaum übersehen. Tritt jedoch ein solches Problem auf, ist es oft viel schwieriger, es zu beheben. Aber der Reihe nach.
Ein wenig Theorie
Der Arbeitsspeicher der virtuellen Maschinen stammt aus dem Speicher der Server, auf denen die VMs laufen. Das ist offensichtlich :). Wenn der Arbeitsspeicher des Servers für alle Benutzer nicht ausreicht, beginnt ESXi, Techniken zur Optimierung der Speichernutzung (memory reclamation techniques) anzuwenden. Andernfalls würden die Betriebssysteme der VMs mit Speicherzugriffsfehlern abstürzen.
Welche Techniken ESXi anwendet, bestimmt sich nach der Auslastung des Arbeitsspeichers:
Speicherzustand
Grenze
Aktionen
Hoch
400% von minFree
Nach Erreichen der oberen Grenze werden große Seiteneinheiten in kleinere zerlegt (TPS arbeitet im Standardmodus).
Clear
100% von minFree
Große Seiten werden in kleinere zerlegt, TPS arbeitet gezwungenermaßen.
Soft
64% von minFree
TPS + Ballooning
Hart
32% von minFree
TPS + Komprimierung + Swap
Niedrig
16% von minFree
Komprimierung + Swap + Blockierung
minFree ist der Arbeitsspeicher, der für den Betrieb des Hypervisors benötigt wird.
Bis einschließlich ESXi 4.1 war minFree standardmäßig festgelegt – auf 6 % des Arbeitsspeichers des Servers (der Prozentsatz konnte über die Option Mem.MinFreePct in ESXi geändert werden). In späteren Versionen wurde minFree aufgrund der gestiegenen Speicherkapazitäten der Server basierend auf dem verfügbaren Host-Speicher berechnet, und nicht mehr als feste Prozentzahl.
Der Wert von minFree (standardmäßig) wird folgendermaßen berechnet:
Prozentsatz des Speichers, der für minFree reserviert ist
Speicherbereich
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Verbleibender Speicher
Zum Beispiel für einen Server mit 128 GB RAM ergibt sich folgender Wert für MinFree:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Der tatsächliche Wert kann um einige Hundert MB abweichen, abhängig vom Server und dem Arbeitsspeicher.
Prozentsatz des Speichers, der für minFree reserviert ist
Speicherbereich
Wert für 128 GB
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Verbleibender Speicher (100 GB)
1024 MB
Für produktive Umgebungen wird normalerweise nur der Zustand "High" als akzeptabel angesehen. Für Test- und Entwicklungsumgebungen können die Zustände "Clear" oder "Soft" jedoch akzeptabel sein. Wenn weniger als 64 % MinFree RAM auf dem Host verbleiben, treten bei den darauf laufenden virtuellen Maschinen sicherlich Leistungsprobleme auf.
In jedem Zustand kommen bestimmte Techniken zur Speicherrückgewinnung zum Einsatz, die von TPS, das nahezu keinen Einfluss auf die Leistung der virtuellen Maschinen hat, bis hin zum Swapping reichen. Ich werde diese Techniken näher erläutern.
Transparent Page Sharing (TPS). TPS ist im Grunde die Deduplikation von RAM-Seiten virtueller Maschinen auf dem Server.
ESXi sucht nach identischen Seiten im RAM der virtuellen Maschinen, indem es die Hash-Summen der Seiten berechnet und vergleicht, und entfernt doppelte Seiten, indem es sie durch Verweise auf dieselbe Seite im physischen RAM des Servers ersetzt. Dadurch wird der physische Speicherverbrauch reduziert, und es kann eine gewisse Überbelegung des Speichers erreicht werden, ohne die Leistung erheblich zu beeinträchtigen.
Dieser Mechanismus funktioniert nur für Speicherseiten mit einer Größe von 4 KB (kleine Seiten). Seiten mit einer Größe von 2 MB (große Seiten) versucht der Hypervisor gar nicht erst zu deduplizieren: Die Wahrscheinlichkeit, identische Seiten dieser Größe zu finden, ist gering.
Standardmäßig reserviert ESXi Speicher für große Seiten. Das Zerteilen großer Seiten in kleine beginnt, wenn der Zustand „High“ erreicht wird, und erfolgt zwangsweise, wenn der Zustand „Clear“ erreicht ist (siehe Zustandstabelle des Hypervisors).
Wenn Sie jedoch möchten, dass TPS zu arbeiten beginnt, ohne darauf zu warten, dass der Arbeitsspeicher des Hosts gefüllt wird, müssen Sie in den erweiterten Optionen von ESXi den Wert einstellen “Mem.AllocGuestLargePage” auf 0 (standardmäßig 1). Dann wird die Zuweisung großer Seiten für virtuelle Maschinen deaktiviert.
Seit Dezember 2014 ist TPS in allen ESXi-Versionen standardmäßig zwischen VMs deaktiviert, da eine Schwachstelle gefunden wurde, die theoretisch den Zugriff einer VM auf den Arbeitsspeicher einer anderen VM ermöglichen könnte. Weitere Details hier. Informationen zur praktischen Ausnutzung der TPS-Schwachstelle sind mir nicht bekannt.
Die TPS-Politik wird über die erweiterte Option “Mem.ShareForceSalting” in ESXi gesteuert:
0 – Inter-VM TPS. TPS funktioniert für Seiten verschiedener VMs;
1 – TPS für VMs mit dem gleichen Wert von “sched.mem.pshare.salt” in VMX;
2 (standardmäßig) – Intra-VM TPS. TPS funktioniert für Seiten innerhalb der VM.
Es macht definitiv Sinn, große Seiten zu deaktivieren und Inter-VM TPS in Testumgebungen zu aktivieren. Dies kann auch für Umgebungen mit einer Vielzahl ähnlicher VMs genutzt werden. Zum Beispiel kann in VDI-Umgebungen die physische Speichereinsparung bis zu mehreren zehn Prozent betragen.
Memory Ballooning. Ballooning ist nicht mehr so harmlos und transparent für das Betriebssystem der VM wie TPS. Doch bei sachgemäßer Anwendung kann man mit Ballooning arbeiten und sogar produktiv sein.
Zusammen mit den VMware Tools wird ein spezieller Treiber namens Balloon Driver (auch vmmemctl) auf der VM installiert. Wenn dem Hypervisor der physische Speicher ausgeht und er in den Zustand Soft wechselt, fordert ESXi die VM auf, ungenutzten Arbeitsspeicher über diesen Balloon Driver zurückzugeben. Der Treiber arbeitet wiederum auf der Ebene des Betriebssystems und fragt freien Speicher dort an. Der Hypervisor sieht, welche Seiten des physischen Speichers vom Balloon Driver belegt sind, entzieht der virtuellen Maschine Speicher und gibt ihn an den Host zurück. Es treten keine Probleme mit dem Betriebssystem auf, da der Speicher auf Betriebssystemebene durch den Balloon Driver belegt ist. Standardmäßig kann der Balloon Driver bis zu 65 % des Speichers der VM zurückfordern.
Wenn die VMware Tools nicht auf der VM installiert sind oder das Ballooning deaktiviert ist (nicht empfohlen, aber möglich :), wechselt der Hypervisor sofort zu drastischeren Methoden der Speicherentnahme. Fazit: Achten Sie darauf, dass die VMware Tools auf der VM installiert sind.
Die Funktion des Balloon Drivers kann über das Betriebssystem mittels VMware Tools überprüft werden..
Speicherkompression. Diese Technik kommt zum Einsatz, wenn ESXi in einen Hard-Zustand übergeht. Wie der Name schon sagt, versucht ESXi, 4 KB Seiten des Arbeitsspeichers auf 2 KB zu komprimieren, um etwas Platz im physischen Speicher des Servers freizugeben. Diese Methode erhöht jedoch erheblich die Zugriffszeiten auf den Inhalt der Arbeitsspeicherseiten der VM, da die Seiten vorher dekomprimiert werden müssen. Manchmal gelingt es nicht, alle Seiten zu komprimieren, und der gesamte Prozess kann einige Zeit in Anspruch nehmen. Daher ist diese Technik in der Praxis nicht besonders effizient.
Speicher-Switching. Nach einer kurzen Phase der Speicherkompression wechselt ESXi praktisch unvermeidlich (es sei denn, die VMs wurden auf andere Hosts verschoben oder abgeschaltet) zum Swapping. Wenn der Speicher fast vollständig erschöpft ist (Zustand Low), hört der Hypervisor auch auf, VMs Speicherseiten zuzuweisen, was in den Gastbetriebssystemen der VMs Probleme verursachen kann.
So funktioniert Swapping. Wenn eine virtuelle Maschine gestartet wird, wird eine Datei mit der Erweiterung .vswp erstellt. Die Größe dieser Datei entspricht dem nicht reservierten Arbeitsspeicher der VM: das ist der Unterschied zwischen dem konfigurierten und dem reservierten Speicher. Während des Swap-Vorgangs entlädt ESXi die Speicherseiten der virtuellen Maschine in diese Datei und arbeitet anstelle des physischen Serverspeichers mit ihr. Selbstverständlich ist dieser "Arbeitsspeicher" um ein Vielfaches langsamer als der echte, selbst wenn .vswp auf einem schnellen Speichermedium liegt.
Im Gegensatz zum Ballooning, bei dem der VM ungenutzte Seiten entzogen werden, können beim Swapping auch Seiten auf die Festplatte verschoben werden, die aktiv von dem Betriebssystem oder Anwendungen innerhalb der VM genutzt werden. Das führt dazu, dass die Performance der VM stark sinkt, bis hin zu einem Hänger. Die VM arbeitet formal und kann mindestens korrekt aus dem Betriebssystem heruntergefahren werden. Seien Sie geduldig 😉
Wenn VMs in den Swap gehen – ist das eine unerwünschte Situation, die nach Möglichkeit vermieden werden sollte.
Die wichtigsten Leistungsindikatoren des Arbeitsspeichers der virtuellen Maschine
Hier sind wir beim Wichtigsten angekommen. Folgende Zähler stehen zur Überwachung des Speicherzustands in der VM zur Verfügung:
Active — zeigt den Arbeitsspeicher (KB) an, auf den die VM im vorherigen Messzeitraum zugegriffen hat.
Nutzung — dasselbe wie Aktiv, jedoch in Prozent der konfigurierten Speicherkapazität der VM. Berechnet mit der folgenden Formel: aktiv ÷ konfigurierten Speichergröße der virtuellen Maschine.
Hohe Nutzung und Aktivität sind nicht immer ein Hinweis auf Leistungsprobleme der VM. Wenn die VM aggressiv auf den Speicher zugreift (mindestens, wenn sie darauf zugreift), bedeutet das nicht, dass der Speicher unzureichend ist. Vielmehr ist es ein Anlass, zu überprüfen, was im Betriebssystem passiert.
Es gibt einen Standard-Alarm für den Arbeitsspeicherverbrauch der VM:
Shared — der Arbeitsspeicher der VM, der durch TPS (innerhalb der VM oder zwischen VMs) dedupliziert wurde.
Zugewiesen — der physische Arbeitsspeicher des Hosts (KB), der der VM zugewiesen wurde. Enthält auch den Shared-Speicher.
Verbraucht (Zugewiesen — Shared) — die Menge an physischem Arbeitsspeicher (KB), die die VM vom Host verbraucht. Enthält nicht den Shared-Speicher.
Wenn ein Teil des Speichers der VM nicht aus dem physischen Arbeitsspeicher des Hosts, sondern aus einer Swap-Datei stammt oder der Speicher über den Balloon Driver von der VM abgezogen wird, wird dieser Teil nicht in Zugewiesen und Verbraucht berücksichtigt.
Hohe Werte für Granted und Consumed sind völlig normal. Das Betriebssystem zieht schrittweise Speicher vom Hypervisor ab und gibt ihn nicht zurück. Im Laufe der Zeit nähern sich die Werte dieser Zähler bei einer aktiv betriebenen VM dem konfigurierten Speichervolumen und verbleiben dort.
Null — der Arbeitsspeicher der VM (KB), der Nullen enthält. Dieser Speicher wird vom Hypervisor als frei angesehen und kann anderen virtuellen Maschinen zugewiesen werden. Sobald das Gastbetriebssystem etwas in den gelegten Speicher geschrieben hat, wechselt es in den Status Consumed und wird nicht mehr zurückgegeben.
Reserved Overhead — der Arbeitsspeicher (KB) der VM, der vom Hypervisor für den Betrieb der VM reserviert ist. Dies ist ein kleiner Speicherbedarf, der jedoch auf dem Host vorhanden sein muss, da die VM sonst nicht gestartet werden kann.
Balloon — der Arbeitsspeicher (KB), der von der VM mit Hilfe des Balloon Drivers entzogen wurde.
Compressed — der Arbeitsspeicher (KB), der komprimiert werden konnte.
Swapped — der Arbeitsspeicher (KB), der aufgrund fehlenden physischen Speichers auf dem Server auf die Festplatte ausgelagert wurde.
Balloon und die anderen Zähler der Memory Reclamation Techniken sind gleich null.
So выглядит das Diagramm mit den Zählern für den Arbeitsspeicher einer normal funktionierenden VM mit 150 GB RAM.
Im Diagramm unten zeigt die VM deutliche Probleme. Unter dem Diagramm ist zu erkennen, dass für diese VM alle beschriebenen Techniken der Arbeitsspeichernutzung angewendet wurden. Der Balloon für diese VM ist deutlich größer als der konsumierte Speicher. Tatsächlich ist die VM eher tot als lebendig.
ESXTOP
Wie bei der CPU, wenn wir die Situation auf dem Host schnell beurteilen und ihre Dynamik im Intervall von bis zu 2 Sekunden bewerten wollen, sollten wir ESXTOP verwenden.
Der ESXTOP-Bildschirm für den Arbeitsspeicher wird mit der Taste „m“ aufgerufen und sieht wie folgt aus (die Felder B, D, H, J, K, L, O wurden ausgewählt):
Für uns sind die folgenden Parameter von Interesse:
Mem overcommit avg – der durchschnittliche Wert der Memory-Überbelegung auf dem Host über 1, 5 und 15 Minuten. Wenn dieser über Null liegt, ist das ein Grund, einen Blick darauf zu werfen, zeigt jedoch nicht immer auf das Vorliegen von Problemen hin.
In den Zeilen PMEM/MB und VMKMEM/MB – Informationen über den physischen Speicher des Servers und den für den VMkernel verfügbaren Speicher. Hier können wir interessante Werte wie minfree (in MB) und den Zustand des Hosts bezüglich des Speichers (in unserem Fall hoch) sehen.
In der Zeile NUMA/MB Sie können die Verteilung des Arbeitsspeichers auf NUMA-Nodes (Sockets) einsehen. In diesem Beispiel ist die Verteilung ungleichmäßig, was grundsätzlich nicht ideal ist.
Hier sind die allgemeinen Statistiken des Servers zu den Techniken der Speicherrückgewinnung:
PSHARE/MB — dies ist die TPS-Statistik;
SWAP/MB — Statistik zur Nutzung des Swaps;
ZIP/MB — Statistik zur Kompression des Arbeitsspeichers;
MEMCTL/MB — Statistik zur Nutzung des Balloon Drivers.
Über die einzelnen VMs könnten wir an folgenden Informationen interessiert sein. Ich habe die VM-Namen anonymisiert, um das Publikum nicht zu verwirren:). Wenn die Metrik ESXTOP dem Zähler in vSphere entspricht, gebe ich den entsprechenden Zähler an.
MEMSZ — der auf der VM konfigurierte Speicher (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
GRANT — Granted in MB.
TCHD — Active in MB.
MCTL? — ob der Balloon Driver auf der VM aktiviert ist.
MCTLSZ — Balloon in MB.
MCTLGT — die Menge an Arbeitsspeicher (MB), die ESXi von der VM über den Balloon Driver entziehen möchte (Memctl Target).
MCTLMAX — die maximale Menge an Arbeitsspeicher (MB), die ESXi von der VM über den Balloon Driver entziehen kann.
SWCUR — die aktuelle Menge an Arbeitsspeicher (MB), die der VM aus der Swap-Datei zugewiesen wurde.
SWGT — die Menge an Arbeitsspeicher (MB), die ESXi der VM aus der Swap-Datei zuweisen möchte (Swap Target).
Über ESXTOP können Sie detailliertere Informationen zur NUMA-Topologie der VM einsehen. Wählen Sie dazu die Felder D, G aus:
NHN – NUMA-Knoten, auf denen die VM liegt. Hier können Sie sofort wide VMs erkennen, die nicht auf einen einzigen NUMA-Knoten passen.
NRMEM – wie viele Megabyte RAM die VM von einem entfernten NUMA-Knoten bezieht.
NLMEM – wie viele Megabyte RAM die VM von einem lokalen NUMA-Knoten bezieht.
N%L – der Prozentsatz des RAMs der VM auf dem lokalen NUMA-Knoten (wenn weniger als 80 % — kann es zu Leistungsproblemen kommen).
Speicher auf dem Hypervisor
Während die CPU-Zähler auf dem Hypervisor normalerweise nicht besonders interessant sind, ist die Situation bei dem Speicher das genaue Gegenteil. Ein hoher Speicherverbrauch auf der VM weist nicht immer auf ein Leistungsproblem hin, jedoch initiiert ein hoher Speicherverbrauch auf dem Hypervisor das Management von Speicher und verursacht Leistungsprobleme der VM. Die Host-Speicherverbrauchs-Alarme sollten überwacht werden, um zu verhindern, dass die VM in den Swap-Bereich gelangt.
Unsuspend
Wenn eine VM in den Swap-Bereich gerät, sinkt ihre Leistung erheblich. Spuren von Ballooning und Kompression verschwinden schnell, sobald wieder freier Arbeitsspeicher auf dem Host verfügbar ist, aber die virtuelle Maschine eilt nicht zurück aus dem Swap in den Arbeitsspeicher des Servers.
Vor Version ESXi 6.0 war der einzige zuverlässige und schnelle Weg, eine VM aus dem Swap zu bringen, ein Neustart (genauer gesagt das Ausschalten/Ein einschalten des Containers). Ab ESXi 6.0 gibt es zwar keine offizielle, aber doch funktionierende und zuverlässige Methode, um eine VM aus dem Swap zu bringen. Auf einer der Konferenzen hatte ich die Gelegenheit, mit einem der Ingenieure von VMware zu sprechen, der für den CPU-Scheduler verantwortlich ist. Er bestätigte, dass die Methode durchaus funktionstüchtig und sicher ist. In unserer Erfahrung gab es damit ebenfalls keine Probleme.
Tatsächlich die Befehle zum Entfernen einer VM aus dem Swap Duncan Epping. Ich werde die detaillierte Beschreibung nicht wiederholen, sondern einfach ein Beispiel für seine Verwendung geben. Wie im Screenshot zu sehen ist, verschwindet der Swap in der VM nach einiger Zeit nach Ausführung des angegebenen Befehls.
Tipps zur Verwaltung des Arbeitsspeichers unter ESXi
Hier sind einige Tipps, die Ihnen helfen, Leistungsprobleme bei VMs aufgrund von RAM zu vermeiden:
- Vermeiden Sie eine Überbelegung des RAM in produktiven Clustern. Es ist ratsam, immer etwa 20-30 % freien Speicher im Cluster zu haben, damit sowohl DRS als auch der Administrator Spielraum für Anpassungen haben und bei der Migration der VMs keine in den Swap geschrieben werden. Vergessen Sie auch nicht den Puffer für Redundanz. Es ist unangenehm, wenn bei einem Serverausfall und dem Neustart der VMs über HA einige Maschinen auch in den Swap gehen.
- In Infrastrukturen mit hoher Konsolidierung sollten Sie versuchen, keine VMs mit mehr als der Hälfte des Hostspeichers zu erstellen. Das wird DRS wieder helfen, die virtuellen Maschinen problemlos auf die Server des Clusters zu verteilen. Dieses Regel ist natürlich nicht universell :).
- Behalten Sie die Warnung zur Host-Speicherauslastung im Auge.
- Vergessen Sie nicht, VMware Tools auf den VMs zu installieren und Balloning nicht zu deaktivieren.
- Erwägen Sie die Aktivierung der Inter-VM TPS und das Deaktivieren von Large Pages in VDI-Umgebungen und Testumgebungen.
- Wenn VMs Leistungsprobleme haben, überprüfen Sie, ob sie auf Speicher von entfernten NUMA-Knoten zugreifen.
- Bringen Sie die VM so schnell wie möglich aus dem Swap! Unter anderem leidet die SAN, wenn die VM im Swap ist, aus offensichtlichen Gründen.
Das war es für meinen Teil über den Arbeitsspeicher. Im Folgenden finden Sie Artikel zu diesem Thema für diejenigen, die tiefer in die Details eintauchen möchten. Der nächste Artikel wird sich mit dem Speicher beschäftigen.
Nützliche Links
Quelle: habr.com
