VM-Leistungsanalyse in VMware vSphere. Teil 2: Erinnerung

Teil 1. Über die CPU
Teil 3. Informationen zur Lagerung

In diesem Artikel werden RAM-Leistungsindikatoren in vSphere behandelt.
Es scheint, dass der Speicher immer eindeutiger ist als beim Prozessor: Wenn auf der VM Leistungsprobleme auftreten, ist es schwierig, diese nicht zu bemerken. Aber wenn sie auftauchen, ist der Umgang mit ihnen viel schwieriger. Aber das Wichtigste zuerst.

Ein bisschen Theorie

Der RAM virtueller Maschinen wird aus dem Speicher des Servers entnommen, auf dem die VMs ausgeführt werden. Das ist ganz offensichtlich :). Wenn der Server-RAM nicht für alle ausreicht, beginnt ESXi, Techniken zur Speicherwiederherstellung anzuwenden. Andernfalls würden die VM-Betriebssysteme mit RAM-Zugriffsfehlern abstürzen.

Welche Techniken zur Verwendung von ESXi verwendet werden, hängt von der RAM-Auslastung ab:
Quelle

minFree ist der RAM, den der Hypervisor benötigt, um zu funktionieren.

Vor ESXi 4.1 einschließlich war minFree standardmäßig festgelegt - 6% des Server-RAM (der Prozentsatz konnte über die Option Mem.MinFreePct unter ESXi geändert werden). In späteren Versionen wurde die Berechnung aufgrund des Anstiegs des Speichervolumens auf minFree-Servern basierend auf der Speichergröße des Hosts und nicht als fester Prozentwert berechnet.

Der minFree-Wert (Standard) wird wie folgt berechnet:
Quelle

Für einen Server mit 128 GB RAM lautet der MinFree-Wert beispielsweise:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Der tatsächliche Wert kann um einige hundert MB abweichen. Dies hängt vom Server und vom RAM ab.


Für produktive Stände kann normalerweise nur Hoch als normal angesehen werden. Für Test- und Entwicklungsstände können klare / weiche Bedingungen akzeptabel sein. Wenn auf dem Host weniger als 64% MinFree RAM vorhanden sind, treten bei den darauf ausgeführten VMs definitiv Leistungsprobleme auf.

In jedem Zustand werden bestimmte Techniken zur Speicherrückgewinnung angewendet, beginnend mit TPS, was die Leistung der VM praktisch nicht beeinträchtigt und mit Swapping endet. Ich werde Ihnen mehr darüber erzählen.

Transparente Seitenfreigabe (TPS). TPS ist grob gesagt die Deduplizierung der RAM-Seiten virtueller Maschinen auf einem Server.

ESXi sucht nach identischen Seiten des Arbeitsspeichers der virtuellen Maschine, zählt und vergleicht die Hash-Summe der Seiten, entfernt doppelte Seiten und ersetzt sie durch Links zu derselben Seite im physischen Speicher des Servers. Infolgedessen wird der physische Speicherverbrauch reduziert, und eine gewisse Neuzuordnung des Speichers kann mit geringem oder keinem Leistungsverlust erreicht werden.


Quelle

Dieser Mechanismus funktioniert nur für 4-kB-Seiten (kleine Seiten). Seiten mit einer Größe von 2 MB (große Seiten) versucht der Hypervisor nicht einmal zu deduplizieren: Die Chance, identische Seiten dieser Größe zu finden, ist nicht groß.

Standardmäßig weist ESXi großen Seiten Speicher zu. Das Aufteilen großer Seiten in kleine Seiten beginnt mit Erreichen des Schwellenwerts für den Status "Hoch" und wird erzwungen, wenn der Status "Löschen" erreicht ist (siehe Tabelle mit dem Hypervisor-Status).

Wenn Sie möchten, dass TPS funktioniert, ohne darauf zu warten, dass der Host-RAM voll ist, müssen Sie in Advanced Options ESXi den Wert „Mem.AllocGuestLargePage“ auf 0 setzen (Standard ist 1). Dann wird die Zuweisung großer Speicherseiten für virtuelle Maschinen deaktiviert.

Seit Dezember 2014 ist in allen ESXi-Versionen TPS zwischen VMs standardmäßig deaktiviert, da eine Sicherheitsanfälligkeit festgestellt wurde, die theoretisch den Zugriff auf den RAM einer anderen VM von einer VM aus ermöglicht. Details hier. Informationen zur praktischen Umsetzung der Ausnutzung der TPS-Sicherheitslücke habe ich nicht getroffen.

Die TPS-Richtlinie wird über die erweiterte Option "Mem.ShareForceSalting" unter ESXi gesteuert:
0 - Inter-VM TPS. TPS funktioniert für Seiten verschiedener VMs.
1 - TPS für VMs mit demselben Wert "sched.mem.pshare.salt" in VMX;
2 (Standard) - Intra-VM TPS. TPS funktioniert für Seiten innerhalb einer VM.

Es ist auf jeden Fall sinnvoll, große Seiten auszuschalten und Inter-VM TPS auf Testbänken zu aktivieren. Es kann auch für Stände mit einer großen Anzahl von VMs des gleichen Typs verwendet werden. Beispielsweise kann an Ständen mit VDI die Einsparung von physischem Speicher mehrere zehn Prozent erreichen.

Gedächtnisballon. Ballonfahren ist für das VM-Betriebssystem keine harmlose und transparente Technik mehr wie TPS. Aber bei richtiger Anwendung mit Ballonfahren können Sie leben und sogar arbeiten.

Zusammen mit Vmware Tools wird auf der VM ein spezieller Treiber installiert, der als Balloon-Treiber (auch bekannt als vmmemctl) bezeichnet wird. Wenn dem Hypervisor der physische Speicher ausgeht und er in den Soft-Status wechselt, fordert ESXi die VM auf, den nicht verwendeten RAM über diesen Ballon-Treiber zurückzugeben. Der Treiber arbeitet wiederum auf Betriebssystemebene und fordert von ihm freien Speicher an. Der Hypervisor erkennt, welche Seiten des physischen Speichers Balloon Driver belegt hat, nimmt den Speicher von der virtuellen Maschine und gibt ihn an den Host zurück. Es gibt keine Probleme mit dem Betrieb des Betriebssystems, da auf Betriebssystemebene der Speicher vom Ballon-Treiber belegt wird. Standardmäßig kann der Ballon-Treiber bis zu 65% des VM-Speichers belegen.

Wenn VMware Tools nicht auf der VM installiert sind oder Ballooning deaktiviert ist (ich empfehle es nicht, aber es gibt KB :), wechselt der Hypervisor sofort zu strengeren Methoden zum Entfernen von Speicher. Fazit: Stellen Sie sicher, dass VMware Tools auf der VM vorhanden sind.


Der Betrieb des Ballon-Treibers kann vom Betriebssystem aus über VMware Tools überprüft werden .

Speicherkomprimierung Diese Technik wird verwendet, wenn ESXi Hard erreicht. Wie der Name schon sagt, versucht ESXi, 4 KB RAM-Seiten auf 2 KB zu komprimieren und so Speicherplatz im physischen Speicher des Servers freizugeben. Diese Technik erhöht die Zugriffszeit auf den Inhalt der Seiten des RAM-Speichers der VM erheblich, da die Seite zuerst gereinigt werden muss. Manchmal können nicht alle Seiten komprimiert werden und der Vorgang selbst dauert einige Zeit. Daher ist diese Technik in der Praxis nicht sehr effektiv.

Speicherwechsel. Nach einer kurzen Phase wechselt Memory Compression ESXi fast zwangsläufig (wenn die VMs nicht zu anderen Hosts gingen oder heruntergefahren wurden) zu Swapping. Wenn nur noch sehr wenig Speicher verfügbar ist (Status "Niedrig"), weist der Hypervisor auch die Zuweisung von VM-Speicherseiten auf, was zu Problemen bei Gast-VMs führen kann.

So funktioniert Swapping. Wenn Sie die virtuelle Maschine einschalten, wird eine Datei mit der Erweiterung .vswp dafür erstellt. Die Größe entspricht dem nicht reservierten RAM der VM: Dies ist der Unterschied zwischen konfiguriertem und reserviertem Speicher. Bei der Arbeit mit Swapping entlädt ESXi die Speicherseiten der virtuellen Maschine in diese Datei und beginnt mit der Arbeit damit anstelle des physischen Speichers des Servers. Natürlich ist ein solcher "RAM" -Speicher mehrere Größenordnungen langsamer als der reale Speicher, selbst wenn .vswp schnell gespeichert wird.

Im Gegensatz zu Ballooning können Seiten, die vom Betriebssystem oder von Anwendungen in der VM aktiv verwendet werden, beim Auslagern auf die Festplatte verschoben werden, wenn nicht verwendete Seiten aus einer VM ausgewählt werden. Infolgedessen sinkt die Leistung der VM, bis sie hängt. VM funktioniert formal und kann zumindest vom Betriebssystem aus korrekt deaktiviert werden. Wenn du geduldig bist;)

Wenn die VMs zu Swap gewechselt sind, ist dies eine abnormale Situation, die nach Möglichkeit am besten vermieden wird.

Grundlegende Leistungsindikatoren für den Arbeitsspeicher der virtuellen Maschine

Also kamen wir zur Hauptsache. Zur Überwachung des Speicherstatus in der VM stehen folgende Zähler zur Verfügung:

Aktiv - Zeigt die RAM-Größe (KB) an, auf die die VM in der vorherigen Messperiode Zugriff erhalten hat.

Die Verwendung entspricht der von "Aktiv", jedoch als Prozentsatz des konfigurierten VM-Speichers. Die Berechnung erfolgt nach folgender Formel: aktiv ÷ Speichergröße der konfigurierten virtuellen Maschine.
Hohe Auslastung bzw. Aktiv weisen nicht immer auf VM-Leistungsprobleme hin. Wenn eine VM aggressiv Speicher verwendet (zumindest Zugriff darauf erhält), bedeutet dies nicht, dass nicht genügend Speicher vorhanden ist. Dies ist vielmehr eine Gelegenheit, um zu sehen, was im Betriebssystem geschieht.
Es gibt einen Standardalarm zur Speichernutzung für VMs:



Shared - Die Menge an RAM in einer VM, die mithilfe von TPS dedupliziert wurde (innerhalb einer VM oder zwischen VMs).

Zugegeben - die Größe des physischen Speichers des Hosts (KB), der der VM zugewiesen wurde. Beinhaltet Shared.

Verbraucht (gewährt - freigegeben) - Die Menge an physischem Speicher (KB), die die VM vom Host verbraucht. Enthält nicht Shared.

Wenn ein Teil des VM-Speichers nicht aus dem physischen Speicher des Hosts zugewiesen wird, sondern aus der Auslagerungsdatei oder der Speicher von der VM über den Balloon-Treiber übernommen wurde, wird dieser Betrag in Granted and Consumed nicht berücksichtigt.
Hohe Werte für gewährt und verbraucht sind völlig normal. Das Betriebssystem nimmt dem Hypervisor nach und nach Speicher ab und gibt ihn nicht zurück. Mit einer aktiv arbeitenden VM nähern sich die Werte dieser Zähler im Laufe der Zeit der Menge des konfigurierten Speichers an und bleiben dort.

Null - Die Größe des Arbeitsspeichers in der VM (KB), die Nullen enthält. Dieser Speicher wird als freier Hypervisor betrachtet und kann an andere virtuelle Maschinen weitergegeben werden. Nachdem das Gastbetriebssystem es erhalten hat, hat es etwas in den Nullspeicher geschrieben, geht zu Consumed und kehrt nicht zurück.

Reservierter Overhead - Die vom Hypervisor reservierte RAM-Größe in der VM (KB), damit die VM funktioniert. Dies ist eine kleine Menge, die jedoch auf dem Host verfügbar sein muss, da sonst die VM nicht gestartet wird.

Ballon - Die Menge an RAM (KB), die mit dem Ballon-Treiber von der VM belegt wurde.

Komprimiert - Die Menge an RAM (KB), die komprimiert werden konnte.

Ausgetauscht - die Größe des Arbeitsspeichers (KB), die mangels physischen Speichers auf dem Server auf die Festplatte verschoben wurde.
Die Zähler für Ballon- und andere Speicherwiederherstellungstechniken sind Null.

So sieht das Diagramm mit den Speicherzählern einer normal funktionierenden VM mit 150 GB RAM aus.



In der folgenden Grafik weist die VM offensichtliche Probleme auf. Die Grafik zeigt, dass für diese VM alle beschriebenen Techniken zum Arbeiten mit RAM verwendet wurden. Der Ballon für diese VM ist viel größer als verbraucht. Tatsächlich ist die VM eher tot als lebendig.

ESXTOP

Wie bei der CPU lohnt es sich, ESXTOP zu verwenden, wenn Sie die Situation auf dem Host sowie dessen Dynamik in einem Intervall von bis zu 2 Sekunden schnell bewerten möchten.

Der ESXTOP-Speicherbildschirm wird mit der Taste „m“ aufgerufen und sieht folgendermaßen aus (Felder B, D, H, J, K, L, O ausgewählt):



Folgende Parameter werden für uns interessant sein:

Mem overcommit avg - Der Durchschnittswert einer Speicherüberbelegung auf einem Host für 1, 5 und 15 Minuten. Wenn über Null, ist dies eine Gelegenheit zu sehen, was passiert, aber nicht immer ein Indikator für das Vorhandensein von Problemen.

In den Zeilen PMEM / MB und VMKMEM / MB - Informationen zum physischen Speicher des Servers und zum für VMkernel verfügbaren Speicher. Aus dem interessanten hier können Sie den Wert minfree (in MB), den Status des Hosts aus dem Speicher (in unserem Fall hoch) sehen.

In der NUMA / MB-Zeile sehen Sie die Verteilung des RAM nach NUMA-Knoten (Sockets). In diesem Beispiel ist die Verteilung ungleichmäßig, was im Prinzip nicht sehr gut ist.

Das Folgende ist eine Zusammenfassung der Serverstatistiken für Speicherwiederherstellungstechniken:

PSHARE / MB ist eine TPS-Statistik.

SWAP / MB - Statistiken zur Verwendung von Swap;

ZIP / MB - Statistik der Komprimierung von Speicherseiten;

MEMCTL / MB - Nutzungsstatistik für Ballontreiber .

Für einzelne VMs interessieren uns möglicherweise die folgenden Informationen. Ich habe die VM-Namen versteckt, um das Publikum nicht in Verlegenheit zu bringen :). Wenn die ESXTOP-Metrik mit dem Zähler in vSphere identisch ist, zitiere ich den entsprechenden Zähler.

MEMSZ ist die auf der VM konfigurierte Speichermenge (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + unberührt.

GRANT - In MB gewährt.

TCHD - Aktiv in MB.

MCTL? - ist auf dem VM Balloon Driver installiert.

MCTLSZ - Ballon in MB.

MCTLGT ist die Menge an RAM (MB), die ESXi über den Balloon-Treiber (Memctl Target) von der VM entfernen möchte.

MCTLMAX - Die maximale RAM-Größe (MB), die ESXi über den Balloon-Treiber von der VM entfernen kann.

SWCUR - Die aktuelle RAM-Größe (MB), die der VM aus der Swap-Datei zugewiesen wurde .

SWGT - Die Menge an RAM (MB), die ESXi VMs aus einer Swap-Datei (Swap Target) zur Verfügung stellen möchte.

Über ESXTOP können Sie auch detailliertere Informationen zur NUMA VM-Topologie anzeigen. Wählen Sie dazu die Felder D, G:



NHN - NUMA-Knoten, auf denen sich die VM befindet. Hier können Sie sofort eine breite VM feststellen, die nicht auf einen NUMA-Knoten passt.

NRMEM - Wie viele Megabyte Speicher benötigt die VM vom Remote-NUMA-Knoten ?

NLMEM - Wie viele Megabyte Speicher benötigt die VM vom lokalen NUMA-Knoten ?

N% L - Prozentsatz des VM-Speichers auf dem lokalen NUMA-Knoten (bei weniger als 80% können Leistungsprobleme auftreten).

Speicher auf dem Hypervisor

Wenn die CPU-Zähler auf dem Hypervisor normalerweise nicht von besonderem Interesse sind, ist die Situation beim Speicher umgekehrt. Eine hohe Speichernutzung auf der VM weist nicht immer auf ein Leistungsproblem hin, aber eine hohe Speichernutzung auf dem Hypervisor startet nur den Speicherverwaltungstechniker und verursacht Probleme mit der Leistung der VM. Alarme zur Verwendung des Hostspeichers müssen überwacht werden, und VMs dürfen Swap nicht betreten.

Auspacken

Wenn die VM in Swap eingestiegen ist, wird ihre Leistung stark reduziert. Ballon- und Komprimierungsspuren verschwinden schnell nach dem Auftreten von freiem RAM auf dem Host, aber die virtuelle Maschine hat es nicht eilig, von Swap zum Server-RAM zurückzukehren.
Vor ESXi 6.0 war der einzige zuverlässige und schnelle Weg, VMs aus Swap zu entfernen, der Neustart (genauer gesagt das Ein- und Ausschalten des Containers). Ab ESXi 6.0 erschien eine nicht so offizielle, aber funktionierende und zuverlässige Möglichkeit, VMs aus Swap herauszuholen. Bei einer der Konferenzen konnte ich mit einem der für den CPU-Scheduler verantwortlichen VMware-Ingenieure sprechen. Er bestätigte, dass die Methode ziemlich funktioniert und sicher ist. Nach unserer Erfahrung wurden auch Probleme mit ihm nicht bemerkt.

Die tatsächlichen Befehle zum Ausgeben von VMs aus Swap wurden von Duncan Epping beschrieben. Ich werde die detaillierte Beschreibung nicht wiederholen, sondern nur ein Beispiel für ihre Verwendung geben. Wie im Screenshot zu sehen ist, verschwindet einige Zeit nach der Ausführung der angegebenen Swap-Befehle auf der VM.

Tipps zum Verwalten des Arbeitsspeichers unter ESXi

Abschließend gebe ich einige Tipps, um Probleme mit der VM-Leistung aufgrund von RAM zu vermeiden:

• Vermeiden Sie eine Überzeichnung des Arbeitsspeichers in produktiven Clustern. Es ist immer ratsam, ~ 20-30% freien Speicher im Cluster zu haben, damit DRS (und der Administrator) Spielraum haben und VMs während der Migration nicht zu Swap wechseln. Vergessen Sie auch nicht den Spielraum für Fehlertoleranz. Es ist unangenehm, wenn, wenn ein Server ausfällt und die VM mit HA neu gestartet wird, einige der Computer auch zu Swap wechseln.
• Versuchen Sie in stark konsolidierten Infrastrukturen NICHT, VMs mit mehr als der Hälfte des Hostspeichers zu erstellen. Dies hilft DRS wiederum dabei, virtuelle Maschinen problemlos auf die Cluster-Server zu verteilen. Diese Regel ist natürlich nicht universell :).
• Achten Sie auf den Alarm zur Verwendung des Hostspeichers.
• Vergessen Sie nicht, VMware Tools auf der VM zu installieren und Ballooning nicht zu deaktivieren.
• Erwägen Sie, Inter-VM TPS zu aktivieren und große Seiten in VDI- und Testumgebungen zu deaktivieren.
• Wenn bei der VM Leistungsprobleme auftreten, überprüfen Sie, ob sie Speicher von einem Remote-NUMA-Knoten verwendet.
• Holen Sie sich VMs so schnell wie möglich aus Swap! Unter anderem leidet das Speichersystem, wenn sich die VM aus offensichtlichen Gründen in Swap befindet.

Das ist alles für RAM. Im Folgenden finden Sie verwandte Artikel für diejenigen, die sich mit den Details befassen möchten. Der nächste Artikel wird der Geschichte gewidmet sein.