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:
Shared â 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
