{"id":35292,"date":"2019-10-31T22:03:28","date_gmt":"2019-10-31T19:03:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory\/"},"modified":"2019-10-31T22:03:28","modified_gmt":"2019-10-31T19:03:28","slug":"analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","title":{"rendered":"Leistungsanalyse von VMs in VMware vSphere. Teil 2: Speicher","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Leistungsanalyse
\n
\nTeil 1. \u00dcber CPU<\/a><\/noindex><\/p>\n

In diesem Artikel sprechen wir \u00fcber die Leistungsindikatoren des Arbeitsspeichers (RAM) in vSphere.
\nAnscheinend ist es mit dem Speicher klarer als mit dem Prozessor: Wenn es bei VMs Leistungsprobleme gibt, sind sie schwer zu \u00fcbersehen. Wenn sie jedoch auftreten, ist es viel schwieriger, sie zu beheben. Aber alles der Reihe nach. <\/a><\/noindex><\/p>\n

Ein wenig Theorie<\/h3>\n

\nDer 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\u00fcnschen gerecht zu werden, beginnt ESXi, Techniken zur Optimierung des Arbeitsspeicherverbrauchs (memory reclamation techniques) anzuwenden. Andernfalls w\u00fcrden die Betriebssysteme der VMs mit Fehlern beim Zugriff auf den RAM abst\u00fcrzen. <\/p>\n

Welche Techniken angewendet werden, entscheidet ESXi je nach Auslastung des Arbeitsspeichers:<\/p>\n

Speicherstatus<\/b><\/p>\n

Grenze<\/b><\/p>\n

Aktionen<\/b><\/p>\n

Hoch<\/p>\n

400% von minFree<\/p>\n

Nachdem die obere Grenze erreicht ist, werden gro\u00dfe Speicherseiten in kleine aufgeteilt (TPS arbeitet im Standardmodus).<\/p>\n

Clear<\/p>\n

100% von minFree<\/p>\n

Gro\u00dfe Speicherseiten werden in kleine aufgeteilt, TPS arbeitet erzwungen.<\/p>\n

Soft<\/p>\n

64% von minFree<\/p>\n

TPS + Balloon<\/p>\n

Hard<\/p>\n

32% von minFree<\/p>\n

TPS + Compress + Swap<\/p>\n

Niedrig<\/p>\n

16% von minFree<\/p>\n

Compress + Swap + Block<\/p>\n

Quelle<\/a><\/noindex> <\/p>\n

minFree ist der Arbeitsspeicher, der f\u00fcr den Betrieb des Hypervisors erforderlich ist. <\/p>\n

Bis einschlie\u00dflich ESXi 4.1 war minFree standardm\u00e4\u00dfig fix \u2014 6% des Arbeitsspeichers des Servers (der Prozentsatz konnte \u00fcber die Option Mem.MinFreePct in ESXi ge\u00e4ndert werden). In sp\u00e4teren Versionen wurde minFree aufgrund des Anstiegs der Speicherkapazit\u00e4ten auf den Servern nicht mehr als fester Prozentsatz, sondern basierend auf dem Gesamtspeicher des Hosts berechnet. <\/p>\n

Der (vorausgesetzte) Wert f\u00fcr minFree wird wie folgt berechnet:<\/p>\n

Prozentsatz des Speichers, der f\u00fcr minFree reserviert ist<\/b><\/p>\n

Speicherbereich<\/b><\/p>\n

6%<\/p>\n

0-4 GB<\/p>\n

4%<\/p>\n

4-12 GB<\/p>\n

2%<\/p>\n

12-28 GB<\/p>\n

1%<\/p>\n

Verbleibender Speicher<\/p>\n

Quelle<\/a><\/noindex><\/p>\n

Zum Beispiel hat ein Server mit 128 GB RAM den folgenden Wert f\u00fcr MinFree:
\nMinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
\nDer tats\u00e4chliche Wert kann um einige hundert MB variieren, dies h\u00e4ngt vom Server und dem Arbeitsspeicher ab.<\/p>\n

Prozentsatz des Speichers, der f\u00fcr minFree reserviert ist<\/b><\/p>\n

Speicherbereich<\/b><\/p>\n

Wert f\u00fcr 128 GB<\/b><\/p>\n

6%<\/p>\n

0-4 GB<\/p>\n

245,76 MB<\/p>\n

4%<\/p>\n

4-12 GB<\/p>\n

327,68 MB<\/p>\n

2%<\/p>\n

12-28 GB<\/p>\n

327,68 MB<\/p>\n

1%<\/p>\n

Verbleibender Speicher (100 GB)<\/p>\n

1024 MB<\/p>\n

\nF\u00fcr produktive St\u00e4nde wird normalerweise nur der Zustand \"High\" als akzeptabel angesehen. F\u00fcr Test- und Entwicklungsst\u00e4nde k\u00f6nnen die Zust\u00e4nde \"Clear\" \/ \"Soft\" akzeptabel sein. Wenn die verf\u00fcgbare Speicherkapazit\u00e4t auf dem Host unter 64 % MinFree liegt, treten bei den darauf laufenden VMs mit Sicherheit Performance-Probleme auf.<\/p>\n

F\u00fcr 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\u00e4her darauf eingehen. <\/p>\n

Transparent Page Sharing (TPS).<\/b> TPS ist, grob gesagt, die Deduplizierung von Seiten des Arbeitsspeichers virtueller Maschinen auf dem Server.<\/p>\n

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 \u00dcberbuchung des Speichers nahezu ohne Leistungseinbu\u00dfen erreichen.<\/p>\n

\"Leistungsanalyse
\nQuelle<\/a><\/noindex><\/p>\n

Dieser Mechanismus funktioniert nur f\u00fcr Seiten mit einer Gr\u00f6\u00dfe von 4 KB (kleine Seiten). Seiten mit einer Gr\u00f6\u00dfe von 2 MB (gro\u00dfe Seiten) versucht der Hypervisor gar nicht zu deduplizieren, da die Wahrscheinlichkeit, identische Seiten dieser Gr\u00f6\u00dfe zu finden, gering ist.<\/p>\n

Standardm\u00e4\u00dfig weist ESXi Speicher gro\u00dfen Seiten zu. Die Aufteilung gro\u00dfer 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\u00e4nde).<\/p>\n

Wenn Sie jedoch m\u00f6chten, dass TPS arbeitet, ohne auf die F\u00fcllung des Arbeitsspeichers des Hosts zu warten, m\u00fcssen Sie in den erweiterten Optionen von ESXi den Wert \u201eMem.AllocGuestLargePage\u201c<\/i> auf 0 (standardm\u00e4\u00dfig 1) setzen. Dann wird die Zuweisung gro\u00dfer Seiten f\u00fcr virtuelle Maschinen deaktiviert.<\/p>\n

Seit Dezember 2014 ist TPS standardm\u00e4\u00dfig 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\u00f6glicht. Details dazu finden Sie hier. Informationen \u00fcber die praktische Umsetzung dieser TPS-Schwachstelle sind mir nicht begegnet.<\/p>\n

Die TPS-Politik wird \u00fcber die erweiterte Option \u201eMem.ShareForceSalting\u201c<\/i> auf ESXi gesteuert:
\n0 \u2014 Inter-VM TPS. TPS funktioniert f\u00fcr Seiten verschiedener VMs;
\n1 \u2014 TPS f\u00fcr VMs mit identischem Wert von \u201esched.mem.pshare.salt\u201c in der VMX;
\n2 (Standard) \u2014 Intra-VM TPS. TPS funktioniert f\u00fcr Seiten innerhalb einer VM.<\/p>\n

Es macht auf jeden Fall Sinn, gro\u00dfe Seiten auszuschalten und Inter-VM TPS auf Testst\u00e4nden zu aktivieren. Dies kann auch f\u00fcr St\u00e4nde mit einer gro\u00dfen Anzahl \u00e4hnlicher VMs verwendet werden. Zum Beispiel kann bei VDI-St\u00e4nden der physische Speicherverbrauch um mehrere Prozent gesenkt werden. <\/p>\n

Memory Ballooning.<\/b> Ballooning ist bereits keine so harmlose und transparente Technik f\u00fcr das Betriebssystem der VM wie TPS. Aber bei richtiger Anwendung kann man mit Ballooning auskommen und sogar arbeiten.<\/p>\n

Zusammen mit VMware Tools wird in der VM ein spezieller Treiber installiert, der als Balloon Driver (auch vmmemctl) bezeichnet wird. Wenn der Hypervisor nicht \u00fcber gen\u00fcgend physischen Speicher verf\u00fcgt und in den Soft-Zustand \u00fcbergeht, fordert ESXi die VM \u00fcber diesen Balloon Driver auf, nicht verwendeten Arbeitsspeicher zur\u00fcckzugeben. 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\u00fcck und gibt ihn an den Host zur\u00fcck. Es entstehen keine Probleme mit dem Betriebssystem, da der Speicher auf Betriebssystemebene durch den Balloon Driver belegt ist. Standardm\u00e4\u00dfig kann der Balloon Driver bis zu 65 % des Speichers der VM zur\u00fccknehmen.<\/p>\n

Wenn VMware Tools nicht auf der VM installiert sind oder Ballooning deaktiviert ist (nicht empfohlen, aber es gibt KB<\/a><\/noindex>:), wechselt der Hypervisor sofort zu drastischeren Techniken des Speicherentzugs. Fazit: Achten Sie darauf, dass VMware Tools auf der VM installiert sind.<\/p>\n

\"Leistungsanalyse
\nDie Funktionsf\u00e4higkeit des Balloon Drivers kann \u00fcber das Betriebssystem mithilfe von VMware Tools \u00fcberpr\u00fcft werden.<\/i>.<\/p>\n

Memory Compression.<\/b> 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\u00f6ht die Zugriffszeit auf den Inhalt der Arbeitsspeicherseiten der VM erheblich, da die Seite vorher dekomprimiert werden muss. Manchmal ist es nicht m\u00f6glich, alle Seiten zu komprimieren, und der ganze Prozess ben\u00f6tigt einige Zeit. Daher ist diese Technik in der Praxis nicht besonders effektiv.<\/p>\n

Memory Swapping.<\/b> 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 \u00fcbergehen. Und wenn nur noch wenig Speicher vorhanden ist (Zustand Low), h\u00f6rt der Hypervisor auch auf, VMs Seiten des Speichers zuzuweisen, was Probleme in den Gastbetriebssystemen der VMs verursachen kann.<\/p>\n

So funktioniert Swapping. Beim Einschalten der virtuellen Maschine wird eine Datei mit der Endung .vswp erstellt. Ihre Gr\u00f6\u00dfe entspricht dem nicht reservierten Arbeitsspeicher der VM: der Unterschied zwischen dem konfigurierten und dem reservierten Speicher. Bei der Swapping-Arbeit entl\u00e4dt ESXi die Speicherseiten der virtuellen Maschine in diese Datei und beginnt, mit ihr anstelle des physischen Speichers des Servers zu arbeiten. Nat\u00fcrlich ist dieser \"Arbeitsspeicher\" um mehrere Gr\u00f6\u00dfenordnungen langsamer als echter Speicher, selbst wenn .vswp auf schnellem Speicher liegt.<\/p>\n

Im Gegensatz zu Ballooning, bei dem einer VM nicht verwendete Seiten entzogen werden, k\u00f6nnen 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\u00e4\u00df aus dem Betriebssystem heruntergefahren werden. Wenn Sie geduldig sind \ud83d\ude09.<\/p>\n

Wenn eine VM in den Swap wechselt, ist dies eine abnormale Situation, die nach M\u00f6glichkeit vermieden werden sollte.<\/p>\n

Wichtige Leistungskennzahlen des Arbeitsspeichers der virtuellen Maschine.<\/h3>\n

\nJetzt sind wir beim Wichtigsten angekommen. Zur \u00dcberwachung des Speicherstatus in der VM gibt es folgende Kennzahlen:<\/p>\n

Active<\/b> \u2014 zeigt die Menge des Arbeitsspeichers (in KByte) an, auf den die VM im vorherigen Messzeitraum Zugriff hatte.<\/p>\n

Nutzung<\/b> \u2014 dasselbe wie Active, jedoch in Prozent des konfigurierten Arbeitsspeichers der VM. Wird nach folgender Formel berechnet: active \u00f7 virtual machine configured memory size.
\nEin hoher Usage- und Active-Wert ist nicht immer ein Indikator f\u00fcr 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.
\nEs gibt einen Standardalarm f\u00fcr den Memory Usage der VM:<\/p>\n

\"Leistungsanalyse
\n
\nGeteilt<\/b> \u2014 der Anteil des Arbeitsspeichers der VM, der durch TPS (innerhalb der VM oder zwischen VMs) dedupliziert wurde.<\/p>\n

Granted<\/b> \u2014 der Anteil des physischen Arbeitsspeichers des Hosts (in KByte), der der VM zugewiesen wurde. Beinhaltet Shared.<\/p>\n

Consumed<\/b> (Granted \u2014 Shared) \u2014 der Anteil des physischen Arbeitsspeichers (in KByte), den die VM vom Host verbraucht. Schlie\u00dft Shared nicht ein.<\/p>\n

Wenn ein Teil des Arbeitsspeichers der VM nicht aus dem physischen Arbeitsspeicher des Hosts, sondern aus einer Swap-Datei bereitgestellt wird oder der Speicher \u00fcber den Balloon Driver der VM entzogen wird, wird dieser Betrag in Granted und Consumed nicht ber\u00fccksichtigt.
\nHohe Werte f\u00fcr Granted und Consumed sind v\u00f6llig normal. Das Betriebssystem nimmt nach und nach Speicher vom Hypervisor und gibt ihn nicht zur\u00fcck. Im Laufe der Zeit n\u00e4hert sich bei einer aktiv betriebenen VM der Wert dieser Z\u00e4hler dem konfigurierten Speicher an, und dort bleibt er.<\/p>\n

Null<\/b> \u2014 der Speicherplatz der VM (KByte), der Nullen enth\u00e4lt. 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\u00fcckgegeben.<\/p>\n

Reserved Overhead<\/b> \u2014 der Speicherplatz der VM (KByte), der vom Hypervisor f\u00fcr 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.<\/p>\n

Balloon<\/b> \u2014 der Speicherplatz (KByte), der von der VM mithilfe des Balloon Drivers entzogen wurde.<\/p>\n

Compressed<\/b> \u2014 der Speicherplatz (KByte), der komprimiert werden konnte.<\/p>\n

Swapped<\/b> \u2014 der Speicherplatz (KByte), der aufgrund fehlenden physischen Speichers auf dem Server auf die Festplatte ausgelagert wurde.
\nBalloon und die anderen Z\u00e4hler der Speicherbereinigungstechniken sind gleich null.<\/p>\n

So sieht das Diagramm mit den Z\u00e4hlern des normal arbeitenden VMs mit 150 GB RAM aus.<\/p>\n

\"Leistungsanalyse
\n
\nIm Diagramm unten hat die VM offensichtlich Probleme. Unter dem Diagramm ist zu erkennen, dass f\u00fcr diese VM alle beschriebenen Techniken zur Speicherverwaltung genutzt wurden. Balloon f\u00fcr diese VM ist wesentlich gr\u00f6\u00dfer als Consumed. Tats\u00e4chlich ist die VM eher tot als lebendig. <\/p>\n

\"Leistungsanalyse
\n<\/p>\n

ESXTOP<\/h3>\n

\nWie bei der CPU, wenn wir die Situation auf dem Host schnell bewerten m\u00f6chten, sowie deren Dynamik in Zeitabst\u00e4nden von bis zu 2 Sekunden, sollten wir ESXTOP verwenden.<\/p>\n

Der ESXTOP-Bildschirm f\u00fcr Memory wird mit der Taste \u201em\u201c aufgerufen und sieht wie folgt aus (die Felder B,D,H,J,K,L,O sind ausgew\u00e4hlt):<\/p>\n

\"Leistungsanalyse
\n
\nInteressant f\u00fcr uns sind die folgenden Parameter: <\/p>\n

Mem overcommit avg<\/b> \u2014 der Durchschnitt der Speichernutzungs\u00fcberschreitung auf dem Host \u00fcber 1, 5 und 15 Minuten. Wenn dieser \u00fcber null liegt, ist das ein Grund, zu \u00fcberpr\u00fcfen, was vor sich geht, aber es ist nicht immer ein Indikator f\u00fcr das Vorhandensein von Problemen.<\/p>\n

In den Zeilen PMEM\/MB<\/b> und VMKMEM\/MB<\/b> \u2014 Informationen \u00fcber den physischen Speicher des Servers und den Speicher, der dem VMkernel zur Verf\u00fcgung 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.<\/p>\n

In der Zeile NUMA\/MB<\/b> man kann die Verteilung des RAM \u00fcber NUMA-Nodes (Sockets) sehen. In diesem Beispiel ist die Verteilung ungleichm\u00e4\u00dfig, was grunds\u00e4tzlich nicht sehr gut ist.<\/p>\n

Hier sind die allgemeinen Statistiken des Servers zu den Techniken der Speicherfreigabe:<\/p>\n

PSHARE\/MB<\/b> \u2014 dies ist die TPS-Statistik;<\/p>\n

SWAP\/MB<\/b> \u2014 Statistiken zur Nutzung von Swap;<\/p>\n

ZIP\/MB<\/b> \u2014 Statistiken zur Komprimierung von Arbeitsspeicherseiten;<\/p>\n

MEMCTL\/MB<\/b> \u2014 Statistiken zur Nutzung des Balloon Drivers.<\/p>\n

F\u00fcr einzelne VMs k\u00f6nnte uns folgende Information interessieren. Ich habe die VM-Namen anonymisiert, um das Publikum nicht zu verwirren:). Wenn die ESXTOP-Metrik dem Z\u00e4hler in vSphere entspricht, f\u00fchre ich den entsprechenden Z\u00e4hler an. <\/p>\n

MEMSZ<\/b> \u2014 der auf der VM konfigurierte Speicher (MB).
\nMEMSZ = GRANT + MCTLSZ + SWCUR + untouched.<\/p>\n

GRANT<\/b> \u2014 Granted in MB.<\/p>\n

TCHD<\/b> \u2014 Active in MB.<\/p>\n

MCTL?<\/b> \u2014 ob der Balloon Driver auf der VM installiert ist.<\/p>\n

MCTLSZ<\/b> \u2014 Balloon in MB.<\/p>\n

MCTLGT<\/b> \u2014 der Arbeitsspeicher (MB), den ESXi von der VM \u00fcber den Balloon Driver abziehen m\u00f6chte (Memctl Target).<\/p>\n

MCTLMAX<\/b> \u2014 maximaler Arbeitsspeicher (MB), den ESXi von der VM \u00fcber den Balloon Driver abziehen kann.<\/p>\n

SWCUR<\/b> \u2014 der aktuelle Arbeitsspeicher (MB), der der VM aus der Swap-Datei zugewiesen ist. <\/p>\n

SWGT<\/b> \u2014 der Arbeitsspeicher (MB), den ESXi der VM aus der Swap-Datei zuweisen m\u00f6chte (Swap Target).<\/p>\n

\u00dcber ESXTOP kann auch detailliertere Informationen zur NUMA-Topologie der VM abgerufen werden. Dazu m\u00fcssen die Felder D,G ausgew\u00e4hlt werden:<\/p>\n

\"Leistungsanalyse
\n
\nNHN<\/b> \u2013 NUMA-Knoten, auf denen die VM liegt. Hier l\u00e4sst sich sofort erkennen, dass breite VMs entstehen, die nicht auf einen einzelnen NUMA-Knoten passen.<\/p>\n

NRMEM<\/b> \u2013 wie viele Megabyte Speicher die VM von einem entfernten NUMA-Knoten nimmt.<\/p>\n

NLMEM<\/b> \u2013 wie viele Megabyte Speicher die VM von einem lokalen NUMA-Knoten nimmt.<\/p>\n

N%L<\/b> \u2013 Prozentsatz des Speichers der VM auf dem lokalen NUMA-Knoten (wenn weniger als 80% \u2014 kann es zu Leistungsproblemen kommen).<\/p>\n

Speicher auf dem Hypervisor<\/h3>\n

\nWenn die CPU-Z\u00e4hler auf dem Hypervisor normalerweise kein besonders gro\u00dfes Interesse wecken, ist die Lage bei dem Speicher genau umgekehrt. Ein hoher Speicherverbrauch auf der VM weist nicht immer auf ein Leistungsproblem hin, w\u00e4hrend ein hoher Speicherverbrauch auf dem Hypervisor dennoch Techniken zur Speicherverwaltung aktiviert und somit Leistungsprobleme der VM verursachen kann. Es ist wichtig, die Alarme f\u00fcr die Verwendung von Host-Speicher zu \u00fcberwachen und zu verhindern, dass die VM in den Swap gelangt.<\/p>\n

\"Leistungsanalyse
\n
\n\"Leistungsanalyse
\n<\/p>\n

Unswap<\/h3>\n

\nWenn 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\u00fcgbar ist, aber die virtuelle Maschine hat es nicht eilig, aus dem Swap in den Arbeitsspeicher des Servers zur\u00fcckzukehren.
\nBis zur Version ESXi 6.0 war der einzige zuverl\u00e4ssige 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\u00e4ssige M\u00f6glichkeit, 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\u00fcr den CPU-Scheduler verantwortlich ist. Er best\u00e4tigte, dass diese Methode durchaus funktioniert und sicher ist. In unserer Erfahrung gab es auch keine Probleme damit.<\/p>\n

Eigentlich die Befehle, um eine VM aus dem Swap zu bringen beschrieben<\/a><\/noindex> Duncan Epping. Ich werde die detaillierte Beschreibung nicht wiederholen, sondern nur ein Beispiel f\u00fcr ihre Anwendung anf\u00fchren. Wie im Screenshot zu sehen ist, verschwindet der Swap f\u00fcr die VM nach einer gewissen Zeit nach Ausf\u00fchrung des angegebenen Befehls.<\/p>\n

\"Leistungsanalyse
\n<\/p>\n

Tipps zur Verwaltung des Arbeitsspeichers auf ESXi<\/h3>\n

\nZum Schluss noch einige Tipps, die Ihnen helfen, Leistungsprobleme der VMs aufgrund von Arbeitsspeicher zu vermeiden:<\/p>\n