In diesem Artikel sprechen wir über die Leistungsindikatoren des Arbeitsspeichers (RAM) in vSphere.
Anscheinend ist es mit dem Speicher klarer als mit dem Prozessor: Wenn es bei VMs Leistungsprobleme gibt, sind sie schwer zu übersehen. Wenn sie jedoch auftreten, ist es viel schwieriger, sie zu beheben. Aber alles der Reihe nach.
Ein wenig Theorie
Der Arbeitsspeicher virtueller Maschinen wird aus dem Speicher der Server entnommen, auf denen die VMs laufen. Das ist recht offensichtlich :). Wenn der Speicher des Servers nicht ausreicht, um allen Wünschen gerecht zu werden, beginnt ESXi, Techniken zur Optimierung des Arbeitsspeicherverbrauchs (memory reclamation techniques) anzuwenden. Andernfalls würden die Betriebssysteme der VMs mit Fehlern beim Zugriff auf den RAM abstürzen.
Welche Techniken angewendet werden, entscheidet ESXi je nach Auslastung des Arbeitsspeichers:
Speicherstatus
Grenze
Aktionen
Hoch
400% von minFree
Nachdem die obere Grenze erreicht ist, werden große Speicherseiten in kleine aufgeteilt (TPS arbeitet im Standardmodus).
Clear
100% von minFree
Große Speicherseiten werden in kleine aufgeteilt, TPS arbeitet erzwungen.
Soft
64% von minFree
TPS + Balloon
Hard
32% von minFree
TPS + Compress + Swap
Niedrig
16% von minFree
Compress + Swap + Block
minFree ist der Arbeitsspeicher, der für den Betrieb des Hypervisors erforderlich ist.
Bis einschließlich ESXi 4.1 war minFree standardmäßig fix — 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 des Anstiegs der Speicherkapazitäten auf den Servern nicht mehr als fester Prozentsatz, sondern basierend auf dem Gesamtspeicher des Hosts berechnet.
Der (vorausgesetzte) Wert für minFree wird wie folgt 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 hat ein Server mit 128 GB RAM den folgenden 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 variieren, dies hängt vom Server und dem Arbeitsspeicher ab.
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 Stände wird normalerweise nur der Zustand "High" als akzeptabel angesehen. Für Test- und Entwicklungsstände können die Zustände "Clear" / "Soft" akzeptabel sein. Wenn die verfügbare Speicherkapazität auf dem Host unter 64 % MinFree liegt, treten bei den darauf laufenden VMs mit Sicherheit Performance-Probleme auf.
Für jeden Zustand kommen bestimmte Techniken zur Speicherfreigabe zum Einsatz, beginnend mit TPS, das praktisch keinen Einfluss auf die VM-Performance hat, bis hin zum Swapping. Ich werde näher darauf eingehen.
Transparent Page Sharing (TPS). TPS ist, grob gesagt, die Deduplizierung von Seiten des Arbeitsspeichers virtueller Maschinen auf dem Server.
ESXi sucht nach identischen Seiten im Arbeitsspeicher der virtuellen Maschinen, indem es die Hash-Summe der Seiten berechnet und vergleicht, und entfernt doppelte Seiten, indem es sie durch Verweise auf dieselbe Seite im physischen Speicher des Servers ersetzt. Dadurch verringert sich der physische Speicherbedarf, und man kann eine gewisse Überbuchung des Speichers nahezu ohne Leistungseinbußen erreichen.
Dieser Mechanismus funktioniert nur für Seiten 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 zu deduplizieren, da die Wahrscheinlichkeit, identische Seiten dieser Größe zu finden, gering ist.
Standardmäßig weist ESXi Speicher großen Seiten zu. Die Aufteilung großer Seiten in kleine Seiten beginnt, wenn der Zustand "High" erreicht ist und erfolgt zwangsweise, wenn der Zustand "Clear" erreicht wird (siehe Tabelle der Hypervisor-Zustände).
Wenn Sie jedoch möchten, dass TPS arbeitet, ohne auf die Füllung des Arbeitsspeichers des Hosts zu warten, müssen Sie in den erweiterten Optionen von ESXi den Wert „Mem.AllocGuestLargePage“ auf 0 (standardmäßig 1) setzen. Dann wird die Zuweisung großer Seiten für virtuelle Maschinen deaktiviert.
Seit Dezember 2014 ist TPS standardmäßig zwischen VMs in allen Versionen von ESXi deaktiviert, da eine Schwachstelle gefunden wurde, die theoretisch den Zugriff von einer VM auf den Arbeitsspeicher einer anderen VM ermöglicht. Details dazu finden Sie hier. Informationen über die praktische Umsetzung dieser TPS-Schwachstelle sind mir nicht begegnet.
Die TPS-Politik wird über die erweiterte Option „Mem.ShareForceSalting“ auf ESXi gesteuert:
0 — Inter-VM TPS. TPS funktioniert für Seiten verschiedener VMs;
1 — TPS für VMs mit identischem Wert von „sched.mem.pshare.salt“ in der VMX;
2 (Standard) — Intra-VM TPS. TPS funktioniert für Seiten innerhalb einer VM.
Es macht auf jeden Fall Sinn, große Seiten auszuschalten und Inter-VM TPS auf Testständen zu aktivieren. Dies kann auch für Stände mit einer großen Anzahl ähnlicher VMs verwendet werden. Zum Beispiel kann bei VDI-Ständen der physische Speicherverbrauch um mehrere Prozent gesenkt werden.
Memory Ballooning. Ballooning ist bereits keine so harmlose und transparente Technik für das Betriebssystem der VM wie TPS. Aber bei richtiger Anwendung kann man mit Ballooning auskommen und sogar arbeiten.
Zusammen mit VMware Tools wird in der VM ein spezieller Treiber installiert, der als Balloon Driver (auch vmmemctl) bezeichnet wird. Wenn der Hypervisor nicht über genügend physischen Speicher verfügt und in den Soft-Zustand übergeht, fordert ESXi die VM über diesen Balloon Driver auf, nicht verwendeten Arbeitsspeicher zurückzugeben. Der Treiber funktioniert seinerseits auf Betriebssystemebene und fordert freien Speicher von ihm an. Der Hypervisor sieht, welche Seiten des physischen Speichers der Balloon Driver belegt hat, nimmt den Speicher von der virtuellen Maschine zurück und gibt ihn an den Host zurück. Es entstehen keine Probleme mit dem Betriebssystem, 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ücknehmen.
Wenn VMware Tools nicht auf der VM installiert sind oder Ballooning deaktiviert ist (nicht empfohlen, aber es gibt :), wechselt der Hypervisor sofort zu drastischeren Techniken des Speicherentzugs. Fazit: Achten Sie darauf, dass VMware Tools auf der VM installiert sind.
Die Funktionsfähigkeit des Balloon Drivers kann über das Betriebssystem mithilfe von VMware Tools überprüft werden..
Memory Compression. Diese Technik wird angewendet, wenn ESXi den Hard-Zustand erreicht. Wie der Name schon sagt, versucht ESXi, eine 4-Kilobyte-Seite des Arbeitsspeichers auf 2 Kilobyte zu komprimieren und dadurch etwas Platz im physischen Speicher des Servers freizugeben. Diese Technik erhöht die Zugriffszeit auf den Inhalt der Arbeitsspeicherseiten der VM erheblich, da die Seite vorher dekomprimiert werden muss. Manchmal ist es nicht möglich, alle Seiten zu komprimieren, und der ganze Prozess benötigt einige Zeit. Daher ist diese Technik in der Praxis nicht besonders effektiv.
Memory Swapping. Nach einer kurzen Phase der Memory Compression wird ESXi nahezu unvermeidlich (es sei denn, die VMs wurden auf andere Hosts verschoben oder wurden ausgeschaltet) zum Swapping übergehen. Und wenn nur noch wenig Speicher vorhanden ist (Zustand Low), hört der Hypervisor auch auf, VMs Seiten des Speichers zuzuweisen, was Probleme in den Gastbetriebssystemen der VMs verursachen kann.
So funktioniert Swapping. Beim Einschalten der virtuellen Maschine wird eine Datei mit der Endung .vswp erstellt. Ihre Größe entspricht dem nicht reservierten Arbeitsspeicher der VM: der Unterschied zwischen dem konfigurierten und dem reservierten Speicher. Bei der Swapping-Arbeit entlädt ESXi die Speicherseiten der virtuellen Maschine in diese Datei und beginnt, mit ihr anstelle des physischen Speichers des Servers zu arbeiten. Natürlich ist dieser "Arbeitsspeicher" um mehrere Größenordnungen langsamer als echter Speicher, selbst wenn .vswp auf schnellem Speicher liegt.
Im Gegensatz zu Ballooning, bei dem einer VM nicht verwendete Seiten entzogen werden, können beim Swapping Seiten auf die Festplatte verschoben werden, die aktiv von dem Betriebssystem oder Anwendungen innerhalb der VM genutzt werden. Infolgedessen sinkt die Leistung der VM bis hin zum Einfrieren. Die VM funktioniert formell weiter und kann mindestens ordnungsgemäß aus dem Betriebssystem heruntergefahren werden. Wenn Sie geduldig sind 😉.
Wenn eine VM in den Swap wechselt, ist dies eine abnormale Situation, die nach Möglichkeit vermieden werden sollte.
Wichtige Leistungskennzahlen des Arbeitsspeichers der virtuellen Maschine.
Jetzt sind wir beim Wichtigsten angekommen. Zur Überwachung des Speicherstatus in der VM gibt es folgende Kennzahlen:
Active — zeigt die Menge des Arbeitsspeichers (in KByte) an, auf den die VM im vorherigen Messzeitraum Zugriff hatte.
Nutzung — dasselbe wie Active, jedoch in Prozent des konfigurierten Arbeitsspeichers der VM. Wird nach folgender Formel berechnet: active ÷ virtual machine configured memory size.
Ein hoher Usage- und Active-Wert ist nicht immer ein Indikator für Leistungsprobleme der VM. Wenn die VM Arbeitsspeicher aggressiv nutzt (mindestens darauf zugreift), bedeutet das nicht, dass der Speicher nicht ausreicht. Vielmehr ist es ein Anlass, sich anzusehen, was im Betriebssystem passiert.
Es gibt einen Standardalarm für den Memory Usage der VM:
Geteilt — der Anteil des Arbeitsspeichers der VM, der durch TPS (innerhalb der VM oder zwischen VMs) dedupliziert wurde.
Granted — der Anteil des physischen Arbeitsspeichers des Hosts (in KByte), der der VM zugewiesen wurde. Beinhaltet Shared.
Consumed (Granted — Shared) — der Anteil des physischen Arbeitsspeichers (in KByte), den die VM vom Host verbraucht. Schließt Shared nicht ein.
Wenn ein Teil des Arbeitsspeichers der VM nicht aus dem physischen Arbeitsspeicher des Hosts, sondern aus einer Swap-Datei bereitgestellt wird oder der Speicher über den Balloon Driver der VM entzogen wird, wird dieser Betrag in Granted und Consumed nicht berücksichtigt.
Hohe Werte für Granted und Consumed sind völlig normal. Das Betriebssystem nimmt nach und nach Speicher vom Hypervisor und gibt ihn nicht zurück. Im Laufe der Zeit nähert sich bei einer aktiv betriebenen VM der Wert dieser Zähler dem konfigurierten Speicher an, und dort bleibt er.
Null — der Speicherplatz der VM (KByte), der Nullen enthält. Dieser Speicher wird vom Hypervisor als frei betrachtet und kann anderen virtuellen Maschinen zugewiesen werden. Sobald das Gastbetriebssystem etwas in den genullten Speicher geschrieben hat, wechselt es zu Consumed und wird nicht zurückgegeben.
Reserved Overhead — der Speicherplatz der VM (KByte), der vom Hypervisor für den Betrieb der VM reserviert ist. Dies ist ein kleiner Speicherbereich, der jedoch auf dem Host vorhanden sein muss, da die VM andernfalls nicht gestartet werden kann.
Balloon — der Speicherplatz (KByte), der von der VM mithilfe des Balloon Drivers entzogen wurde.
Compressed — der Speicherplatz (KByte), der komprimiert werden konnte.
Swapped — der Speicherplatz (KByte), der aufgrund fehlenden physischen Speichers auf dem Server auf die Festplatte ausgelagert wurde.
Balloon und die anderen Zähler der Speicherbereinigungstechniken sind gleich null.
So sieht das Diagramm mit den Zählern des normal arbeitenden VMs mit 150 GB RAM aus.
Im Diagramm unten hat die VM offensichtlich Probleme. Unter dem Diagramm ist zu erkennen, dass für diese VM alle beschriebenen Techniken zur Speicherverwaltung genutzt wurden. Balloon für diese VM ist wesentlich größer als Consumed. Tatsächlich ist die VM eher tot als lebendig.
ESXTOP
Wie bei der CPU, wenn wir die Situation auf dem Host schnell bewerten möchten, sowie deren Dynamik in Zeitabständen von bis zu 2 Sekunden, sollten wir ESXTOP verwenden.
Der ESXTOP-Bildschirm für Memory wird mit der Taste „m“ aufgerufen und sieht wie folgt aus (die Felder B,D,H,J,K,L,O sind ausgewählt):
Interessant für uns sind die folgenden Parameter:
Mem overcommit avg — der Durchschnitt der Speichernutzungsüberschreitung auf dem Host über 1, 5 und 15 Minuten. Wenn dieser über null liegt, ist das ein Grund, zu überprüfen, was vor sich geht, aber es ist nicht immer ein Indikator für das Vorhandensein von Problemen.
In den Zeilen PMEM/MB und VMKMEM/MB — Informationen über den physischen Speicher des Servers und den Speicher, der dem VMkernel zur Verfügung steht. Hier kann man interessante Werte wie minfree (in MByte) und den Zustand des Hosts im Hinblick auf den Speicher (in unserem Fall hoch) sehen.
In der Zeile NUMA/MB man kann die Verteilung des RAM über NUMA-Nodes (Sockets) sehen. In diesem Beispiel ist die Verteilung ungleichmäßig, was grundsätzlich nicht sehr gut ist.
Hier sind die allgemeinen Statistiken des Servers zu den Techniken der Speicherfreigabe:
PSHARE/MB — dies ist die TPS-Statistik;
SWAP/MB — Statistiken zur Nutzung von Swap;
ZIP/MB — Statistiken zur Komprimierung von Arbeitsspeicherseiten;
MEMCTL/MB — Statistiken zur Nutzung des Balloon Drivers.
Für einzelne VMs könnte uns folgende Information interessieren. Ich habe die VM-Namen anonymisiert, um das Publikum nicht zu verwirren:). Wenn die ESXTOP-Metrik dem Zähler in vSphere entspricht, führe 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 installiert ist.
MCTLSZ — Balloon in MB.
MCTLGT — der Arbeitsspeicher (MB), den ESXi von der VM über den Balloon Driver abziehen möchte (Memctl Target).
MCTLMAX — maximaler Arbeitsspeicher (MB), den ESXi von der VM über den Balloon Driver abziehen kann.
SWCUR — der aktuelle Arbeitsspeicher (MB), der der VM aus der Swap-Datei zugewiesen ist.
SWGT — der Arbeitsspeicher (MB), den ESXi der VM aus der Swap-Datei zuweisen möchte (Swap Target).
Über ESXTOP kann auch detailliertere Informationen zur NUMA-Topologie der VM abgerufen werden. Dazu müssen die Felder D,G ausgewählt werden:
NHN – NUMA-Knoten, auf denen die VM liegt. Hier lässt sich sofort erkennen, dass breite VMs entstehen, die nicht auf einen einzelnen NUMA-Knoten passen.
NRMEM – wie viele Megabyte Speicher die VM von einem entfernten NUMA-Knoten nimmt.
NLMEM – wie viele Megabyte Speicher die VM von einem lokalen NUMA-Knoten nimmt.
N%L – Prozentsatz des Speichers der VM auf dem lokalen NUMA-Knoten (wenn weniger als 80% — kann es zu Leistungsproblemen kommen).
Speicher auf dem Hypervisor
Wenn die CPU-Zähler auf dem Hypervisor normalerweise kein besonders großes Interesse wecken, ist die Lage bei dem Speicher genau umgekehrt. Ein hoher Speicherverbrauch auf der VM weist nicht immer auf ein Leistungsproblem hin, während ein hoher Speicherverbrauch auf dem Hypervisor dennoch Techniken zur Speicherverwaltung aktiviert und somit Leistungsprobleme der VM verursachen kann. Es ist wichtig, die Alarme für die Verwendung von Host-Speicher zu überwachen und zu verhindern, dass die VM in den Swap gelangt.
Unswap
Wenn die VM in den Swap geraten ist, sinkt ihre Leistung erheblich. Die Hinweise auf Ballooning und Komprimierung verschwinden schnell, sobald wieder ausreichend Arbeitsspeicher auf dem Host verfügbar ist, aber die virtuelle Maschine hat es nicht eilig, aus dem Swap in den Arbeitsspeicher des Servers zurückzukehren.
Bis zur 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/ Einschalten des Containers). Mit ESXi 6.0 gab es zwar eine nicht ganz offizielle, aber funktionierende und zuverlässige Möglichkeit, 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 diese Methode durchaus funktioniert und sicher ist. In unserer Erfahrung gab es auch keine Probleme damit.
Eigentlich die Befehle, um eine VM aus dem Swap zu bringen Duncan Epping. Ich werde die detaillierte Beschreibung nicht wiederholen, sondern nur ein Beispiel für ihre Anwendung anführen. Wie im Screenshot zu sehen ist, verschwindet der Swap für die VM nach einer gewissen Zeit nach Ausführung des angegebenen Befehls.
Tipps zur Verwaltung des Arbeitsspeichers auf ESXi
Zum Schluss noch einige Tipps, die Ihnen helfen, Leistungsprobleme der VMs aufgrund von Arbeitsspeicher zu vermeiden:
- Vermeiden Sie eine Überbuchung des Arbeitsspeichers in Produktions-Clustern. Es ist ratsam, stets etwa 20-30 % freien Speicher im Cluster zu haben, damit DRS (und der Administrator) Spielraum zur Verfügung hat und bei der Migration der VMs nicht in den Swap wechseln. Denken Sie auch an die Reserve für die Ausfallsicherheit. Es ist unangenehm, wenn bei einem Ausfall eines Servers und der Neustart der VMs mit HA einige Maschinen zudem in den Swap wechseln.
- In Infrastrukturen mit hoher Konsolidierung sollten Sie vermeiden, VMs mit mehr als der Hälfte des Hosts Arbeitsspeicher zu erstellen. Das hilft DRS erneut, die virtuellen Maschinen problemlos auf den Servern des Clusters zu verteilen. Diese Regel ist natürlich nicht universell.
- Achten Sie auf die Host Memory Usage Alarm.
- Vergessen Sie nicht, VMware Tools auf den VMs zu installieren und Ballooning nicht zu deaktivieren.
- Erwägen Sie die Möglichkeit, Inter-VM TPS zu aktivieren und Large Pages in VDI-Umgebungen und Testumgebungen zu deaktivieren.
- Wenn eine VM Leistungsprobleme hat, überprüfen Sie, ob sie Speicher von einem entfernten NUMA-Knoten verwendet.
- Bringen Sie die VMs so schnell wie möglich aus dem Swap! Neben allem anderen leidet die Storage-Performance, wenn die VMs im Swap sind.
Das wäre alles zum Thema Arbeitsspeicher. Nachfolgend finden Sie Artikel zu diesem Thema für diejenigen, die sich intensiver mit den Details befassen möchten. Der nächste Artikel wird dem Storage gewidmet sein.
Nützliche Links
Quelle: habr.com
