{"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: Arbeitsspeicher","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 Leistungsmessungen des Arbeitsspeichers (RAM) in vSphere.
\nBei der Arbeitsspeicher-Leistung scheint alles eindeutiger zu sein als bei der CPU: Wenn es bei einer VM zu Leistungsproblemen kommt, kann man dies kaum \u00fcbersehen. Tritt jedoch ein solches Problem auf, ist es oft viel schwieriger, es zu beheben. Aber der Reihe nach. <\/a><\/noindex><\/p>\n

Ein wenig Theorie<\/h3>\n

\nDer Arbeitsspeicher der virtuellen Maschinen stammt aus dem Speicher der Server, auf denen die VMs laufen. Das ist offensichtlich :). Wenn der Arbeitsspeicher des Servers f\u00fcr alle Benutzer nicht ausreicht, beginnt ESXi, Techniken zur Optimierung der Speichernutzung (memory reclamation techniques) anzuwenden. Andernfalls w\u00fcrden die Betriebssysteme der VMs mit Speicherzugriffsfehlern abst\u00fcrzen. <\/p>\n

Welche Techniken ESXi anwendet, bestimmt sich nach der Auslastung des Arbeitsspeichers:<\/p>\n

Speicherzustand<\/b><\/p>\n

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

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

Hoch<\/p>\n

400% von minFree<\/p>\n

Nach Erreichen der oberen Grenze werden gro\u00dfe Seiteneinheiten in kleinere zerlegt (TPS arbeitet im Standardmodus).<\/p>\n

Clear<\/p>\n

100% von minFree<\/p>\n

Gro\u00dfe Seiten werden in kleinere zerlegt, TPS arbeitet gezwungenerma\u00dfen.<\/p>\n

Soft<\/p>\n

64% von minFree<\/p>\n

TPS + Ballooning<\/p>\n

Hart<\/p>\n

32% von minFree<\/p>\n

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

Niedrig<\/p>\n

16% von minFree<\/p>\n

Komprimierung + Swap + Blockierung<\/p>\n

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

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

Bis einschlie\u00dflich ESXi 4.1 war minFree standardm\u00e4\u00dfig festgelegt \u2013 auf 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 der gestiegenen Speicherkapazit\u00e4ten der Server basierend auf dem verf\u00fcgbaren Host-Speicher berechnet, und nicht mehr als feste Prozentzahl. <\/p>\n

Der Wert von minFree (standardm\u00e4\u00dfig) wird folgenderma\u00dfen 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 f\u00fcr einen Server mit 128 GB RAM ergibt sich folgender 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 abweichen, abh\u00e4ngig vom Server und dem Arbeitsspeicher.<\/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 Umgebungen wird normalerweise nur der Zustand \"High\" als akzeptabel angesehen. F\u00fcr Test- und Entwicklungsumgebungen k\u00f6nnen die Zust\u00e4nde \"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.<\/p>\n

In jedem Zustand kommen bestimmte Techniken zur Speicherr\u00fcckgewinnung 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\u00e4her erl\u00e4utern. <\/p>\n

Transparent Page Sharing (TPS).<\/b> TPS ist im Grunde die Deduplikation von RAM-Seiten virtueller Maschinen auf dem Server.<\/p>\n

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 \u00dcberbelegung des Speichers erreicht werden, ohne die Leistung erheblich zu beeintr\u00e4chtigen.<\/p>\n

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

Dieser Mechanismus funktioniert nur f\u00fcr Speicherseiten 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 erst zu deduplizieren: Die Wahrscheinlichkeit, identische Seiten dieser Gr\u00f6\u00dfe zu finden, ist gering.<\/p>\n

Standardm\u00e4\u00dfig reserviert ESXi Speicher f\u00fcr gro\u00dfe Seiten. Das Zerteilen gro\u00dfer Seiten in kleine beginnt, wenn der Zustand \u201eHigh\u201c erreicht wird, und erfolgt zwangsweise, wenn der Zustand \u201eClear\u201c erreicht ist (siehe Zustandstabelle des Hypervisors).<\/p>\n

Wenn Sie jedoch m\u00f6chten, dass TPS zu arbeiten beginnt, ohne darauf zu warten, dass der Arbeitsspeicher des Hosts gef\u00fcllt wird, m\u00fcssen Sie in den erweiterten Optionen von ESXi den Wert einstellen \u201cMem.AllocGuestLargePage\u201d<\/i> auf 0 (standardm\u00e4\u00dfig 1). Dann wird die Zuweisung gro\u00dfer Seiten f\u00fcr virtuelle Maschinen deaktiviert.<\/p>\n

Seit Dezember 2014 ist TPS in allen ESXi-Versionen standardm\u00e4\u00dfig zwischen VMs deaktiviert, da eine Schwachstelle gefunden wurde, die theoretisch den Zugriff einer VM auf den Arbeitsspeicher einer anderen VM erm\u00f6glichen k\u00f6nnte. Weitere Details hier. Informationen zur praktischen Ausnutzung der TPS-Schwachstelle sind mir nicht bekannt.<\/p>\n

Die TPS-Politik wird \u00fcber die erweiterte Option \u201cMem.ShareForceSalting\u201d<\/i> in ESXi gesteuert:
\n0 \u2013 Inter-VM TPS. TPS funktioniert f\u00fcr Seiten verschiedener VMs;
\n1 \u2013 TPS f\u00fcr VMs mit dem gleichen Wert von \u201csched.mem.pshare.salt\u201d in VMX;
\n2 (standardm\u00e4\u00dfig) \u2013 Intra-VM TPS. TPS funktioniert f\u00fcr Seiten innerhalb der VM.<\/p>\n

Es macht definitiv Sinn, gro\u00dfe Seiten zu deaktivieren und Inter-VM TPS in Testumgebungen zu aktivieren. Dies kann auch f\u00fcr Umgebungen mit einer Vielzahl \u00e4hnlicher VMs genutzt werden. Zum Beispiel kann in VDI-Umgebungen die physische Speichereinsparung bis zu mehreren zehn Prozent betragen. <\/p>\n

Memory Ballooning.<\/b> Ballooning ist nicht mehr so harmlos und transparent f\u00fcr das Betriebssystem der VM wie TPS. Doch bei sachgem\u00e4\u00dfer Anwendung kann man mit Ballooning arbeiten und sogar produktiv sein.<\/p>\n

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 \u00fcber diesen Balloon Driver zur\u00fcckzugeben. 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\u00fcck. Es treten keine Probleme mit dem Betriebssystem auf, 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\u00fcckfordern.<\/p>\n

Wenn die VMware Tools nicht auf der VM installiert sind oder das Ballooning deaktiviert ist (nicht empfohlen, aber m\u00f6glich KB<\/a><\/noindex>:), wechselt der Hypervisor sofort zu drastischeren Methoden der Speicherentnahme. Fazit: Achten Sie darauf, dass die VMware Tools auf der VM installiert sind.<\/p>\n

\"Leistungsanalyse
\nDie Funktion des Balloon Drivers kann \u00fcber das Betriebssystem mittels VMware Tools \u00fcberpr\u00fcft werden.<\/i>.<\/p>\n

Speicherkompression.<\/b> Diese Technik kommt zum Einsatz, wenn ESXi in einen Hard-Zustand \u00fcbergeht. 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\u00f6ht jedoch erheblich die Zugriffszeiten auf den Inhalt der Arbeitsspeicherseiten der VM, da die Seiten vorher dekomprimiert werden m\u00fcssen. 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.<\/p>\n

Speicher-Switching.<\/b> 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\u00e4ndig ersch\u00f6pft ist (Zustand Low), h\u00f6rt der Hypervisor auch auf, VMs Speicherseiten zuzuweisen, was in den Gastbetriebssystemen der VMs Probleme verursachen kann.<\/p>\n

So funktioniert Swapping. Wenn eine virtuelle Maschine gestartet wird, wird eine Datei mit der Erweiterung .vswp erstellt. Die Gr\u00f6\u00dfe dieser Datei entspricht dem nicht reservierten Arbeitsspeicher der VM: das ist der Unterschied zwischen dem konfigurierten und dem reservierten Speicher. W\u00e4hrend des Swap-Vorgangs entl\u00e4dt ESXi die Speicherseiten der virtuellen Maschine in diese Datei und arbeitet anstelle des physischen Serverspeichers mit ihr. Selbstverst\u00e4ndlich ist dieser \"Arbeitsspeicher\" um ein Vielfaches langsamer als der echte, selbst wenn .vswp auf einem schnellen Speichermedium liegt.<\/p>\n

Im Gegensatz zum Ballooning, bei dem der VM ungenutzte Seiten entzogen werden, k\u00f6nnen beim Swapping auch Seiten auf die Festplatte verschoben werden, die aktiv von dem Betriebssystem oder Anwendungen innerhalb der VM genutzt werden. Das f\u00fchrt dazu, dass die Performance der VM stark sinkt, bis hin zu einem H\u00e4nger. Die VM arbeitet formal und kann mindestens korrekt aus dem Betriebssystem heruntergefahren werden. Seien Sie geduldig \ud83d\ude09<\/p>\n

Wenn VMs in den Swap gehen \u2013 ist das eine unerw\u00fcnschte Situation, die nach M\u00f6glichkeit vermieden werden sollte.<\/p>\n

Die wichtigsten Leistungsindikatoren des Arbeitsspeichers der virtuellen Maschine<\/h3>\n

\nHier sind wir beim Wichtigsten angekommen. Folgende Z\u00e4hler stehen zur \u00dcberwachung des Speicherzustands in der VM zur Verf\u00fcgung:<\/p>\n

Active<\/b> \u2014 zeigt den Arbeitsspeicher (KB) an, auf den die VM im vorherigen Messzeitraum zugegriffen hat.<\/p>\n

Nutzung<\/b> \u2014 dasselbe wie Aktiv, jedoch in Prozent der konfigurierten Speicherkapazit\u00e4t der VM. Berechnet mit der folgenden Formel: aktiv \u00f7 konfigurierten Speichergr\u00f6\u00dfe der virtuellen Maschine.
\nHohe Nutzung und Aktivit\u00e4t 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 \u00fcberpr\u00fcfen, was im Betriebssystem passiert.
\nEs gibt einen Standard-Alarm f\u00fcr den Arbeitsspeicherverbrauch der VM:<\/p>\n

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

Zugewiesen<\/b> \u2014 der physische Arbeitsspeicher des Hosts (KB), der der VM zugewiesen wurde. Enth\u00e4lt auch den Shared-Speicher.<\/p>\n

Verbraucht<\/b> (Zugewiesen \u2014 Shared) \u2014 die Menge an physischem Arbeitsspeicher (KB), die die VM vom Host verbraucht. Enth\u00e4lt nicht den Shared-Speicher.<\/p>\n

Wenn ein Teil des Speichers der VM nicht aus dem physischen Arbeitsspeicher des Hosts, sondern aus einer Swap-Datei stammt oder der Speicher \u00fcber den Balloon Driver von der VM abgezogen wird, wird dieser Teil nicht in Zugewiesen und Verbraucht ber\u00fccksichtigt.
\nHohe Werte f\u00fcr Granted und Consumed sind v\u00f6llig normal. Das Betriebssystem zieht schrittweise Speicher vom Hypervisor ab und gibt ihn nicht zur\u00fcck. Im Laufe der Zeit n\u00e4hern sich die Werte dieser Z\u00e4hler bei einer aktiv betriebenen VM dem konfigurierten Speichervolumen und verbleiben dort.<\/p>\n

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

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

Balloon<\/b> \u2014 der Arbeitsspeicher (KB), der von der VM mit Hilfe des Balloon Drivers entzogen wurde.<\/p>\n

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

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

So \u0432\u044b\u0433\u043b\u044f\u0434\u0438\u0442 das Diagramm mit den Z\u00e4hlern f\u00fcr den Arbeitsspeicher einer normal funktionierenden VM mit 150 GB RAM.<\/p>\n

\"Leistungsanalyse
\n
\nIm Diagramm unten zeigt die VM deutliche Probleme. Unter dem Diagramm ist zu erkennen, dass f\u00fcr diese VM alle beschriebenen Techniken der Arbeitsspeichernutzung angewendet wurden. Der Balloon f\u00fcr diese VM ist deutlich gr\u00f6\u00dfer als der konsumierte Speicher. 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 beurteilen und ihre Dynamik im Intervall von bis zu 2 Sekunden bewerten wollen, sollten wir ESXTOP verwenden.<\/p>\n

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

\"Leistungsanalyse
\n
\nF\u00fcr uns sind die folgenden Parameter von Interesse: <\/p>\n

Mem overcommit avg<\/b> \u2013 der durchschnittliche Wert der Memory-\u00dcberbelegung auf dem Host \u00fcber 1, 5 und 15 Minuten. Wenn dieser \u00fcber Null liegt, ist das ein Grund, einen Blick darauf zu werfen, zeigt jedoch nicht immer auf das Vorliegen von Problemen hin.<\/p>\n

In den Zeilen PMEM\/MB<\/b> und VMKMEM\/MB<\/b> \u2013 Informationen \u00fcber den physischen Speicher des Servers und den f\u00fcr den VMkernel verf\u00fcgbaren Speicher. Hier k\u00f6nnen wir interessante Werte wie minfree (in MB) und den Zustand des Hosts bez\u00fcglich des Speichers (in unserem Fall hoch) sehen.<\/p>\n

In der Zeile NUMA\/MB<\/b> Sie k\u00f6nnen die Verteilung des Arbeitsspeichers auf NUMA-Nodes (Sockets) einsehen. In diesem Beispiel ist die Verteilung ungleichm\u00e4\u00dfig, was grunds\u00e4tzlich nicht ideal ist.<\/p>\n

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

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

SWAP\/MB<\/b> \u2014 Statistik zur Nutzung des Swaps;<\/p>\n

ZIP\/MB<\/b> \u2014 Statistik zur Kompression des Arbeitsspeichers;<\/p>\n

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

\u00dcber die einzelnen VMs k\u00f6nnten wir an folgenden Informationen interessiert sein. Ich habe die VM-Namen anonymisiert, um das Publikum nicht zu verwirren:). Wenn die Metrik ESXTOP dem Z\u00e4hler in vSphere entspricht, gebe 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 aktiviert ist.<\/p>\n

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

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

MCTLMAX<\/b> \u2014 die maximale Menge an Arbeitsspeicher (MB), die ESXi von der VM \u00fcber den Balloon Driver entziehen kann.<\/p>\n

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

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

\u00dcber ESXTOP k\u00f6nnen Sie detailliertere Informationen zur NUMA-Topologie der VM einsehen. W\u00e4hlen Sie dazu die Felder D, G aus:<\/p>\n

\"Leistungsanalyse
\n
\nNHN<\/b> \u2013 NUMA-Knoten, auf denen die VM liegt. Hier k\u00f6nnen Sie sofort wide VMs erkennen, die nicht auf einen einzigen NUMA-Knoten passen.<\/p>\n

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

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

N%L<\/b> \u2013 der Prozentsatz des RAMs 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

\nW\u00e4hrend die CPU-Z\u00e4hler 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 \u00fcberwacht werden, um zu verhindern, dass die VM in den Swap-Bereich gelangt.<\/p>\n

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

Unsuspend<\/h3>\n

\nWenn eine VM in den Swap-Bereich ger\u00e4t, sinkt ihre Leistung erheblich. Spuren von Ballooning und Kompression verschwinden schnell, sobald wieder freier Arbeitsspeicher auf dem Host verf\u00fcgbar ist, aber die virtuelle Maschine eilt nicht zur\u00fcck aus dem Swap in den Arbeitsspeicher des Servers.
\nVor 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\/Ein einschalten des Containers). Ab ESXi 6.0 gibt es zwar keine offizielle, aber doch funktionierende und zuverl\u00e4ssige 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\u00fcr den CPU-Scheduler verantwortlich ist. Er best\u00e4tigte, dass die Methode durchaus funktionst\u00fcchtig und sicher ist. In unserer Erfahrung gab es damit ebenfalls keine Probleme.<\/p>\n

Tats\u00e4chlich die Befehle zum Entfernen einer VM aus dem Swap beschrieb<\/a><\/noindex> Duncan Epping. Ich werde die detaillierte Beschreibung nicht wiederholen, sondern einfach ein Beispiel f\u00fcr seine Verwendung geben. Wie im Screenshot zu sehen ist, verschwindet der Swap in der VM nach einiger Zeit nach Ausf\u00fchrung des angegebenen Befehls.<\/p>\n

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

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

\nHier sind einige Tipps, die Ihnen helfen, Leistungsprobleme bei VMs aufgrund von RAM zu vermeiden:<\/p>\n