VMware Memory Ballooning und ESXi Swapping: wie vSphere bei Speicherüberbelegung Arbeitsspeicher zurückgewinnt

Wie ESX bei Speicherüberbelegung in vSphere Arbeitsspeicher zurückgewinnt

Brauchen die VMs auf einem Host mehr Arbeitsspeicher, als der Host hat, liegt eine Speicherüberbelegung vor, und ESX holt sich Arbeitsspeicher von den VMs zurück. Broadcoms Performance Best Practices for vSphere 9.0 (Revision 20250731) nennen dafür fünf Mechanismen: Page Sharing, Ballooning, Speicherkomprimierung, Swapping in den Host-Cache und reguläres Swapping. Die letzten vier kommen in dieser Reihenfolge zum Einsatz, wenn der Arbeitsspeicher des Hosts knapp wird. Etwas Ballooning ist „ganz normal und kein Hinweis auf ein Problem“, wie derselbe Leitfaden schreibt. Anhaltendes Ballooning und Host-Swapping bedeuten meist, dass der aktive Arbeitsspeicher der VMs nicht in den physischen Arbeitsspeicher des Hosts passt oder dass ein Speicherlimit eine VM unter dem hält, was sie anfordert.

Überbelegung im Sinne Broadcoms bezieht sich auf den genutzten Arbeitsspeicher (Working Memory), nicht auf den konfigurierten. Die Dokumentation zu vSphere 9.1 (29. September 2026) sagt, dass der konfigurierte Arbeitsspeicher aller VMs „die Menge des verfügbaren physischen Arbeitsspeichers auf dem ESX-Host übersteigen kann“, was „nicht unbedingt bedeutet, dass der Arbeitsspeicher überbelegt ist“. Broadcom knüpft die Überbelegung daran, dass „der kombinierte Arbeitsspeicher-Footprint aller virtuellen Maschinen“ den Arbeitsspeicher des Hosts übersteigt.

Performance Best Practices for VMware vSphere 9.0 (Revision 20250731); Broadcom TechDocs, Resource Management für vSphere 8.0 und 9.1 (16. bis 29. September 2026), Memory Tiering Considerations (12. Oktober 2026); KB 374743.

Speicherzustände in esxtop: high, clear, soft, hard und low

Die Speicheransicht von esxtop zeigt den Zustand des Hosts in der Zeile VMKMEM. Die esxtop-Dokumentation dieser Ansicht für vSphere 8.0 (16. September 2026) und 9.1 (12. Oktober 2026) schreibt „Mögliche Werte sind high, soft, hard und low“ und „High bedeutet, dass der Maschinenspeicher unter keinerlei Druck steht, und low bedeutet, dass er es tut.“ Broadcoms KB 374743, verfasst für ESXi 7.0 und 8.0, nennt einen fünften Zustand und die Reihenfolge: „High state > Clear state > Soft State > Hard State > Low State“.

Ein aktuelles Broadcom-Dokument, das die Menge an freiem Arbeitsspeicher veröffentlicht, bei der ein Host von einem Zustand in den nächsten wechselt, oder das jede Technik einem Zustand zuordnet, haben wir nicht gefunden. Die Diagrammdokumentation zu vSphere 8.0 nennt stattdessen zwei Werte auf Host-Ebene: Eine dauerhaft hohe Speichernutzung von 94 % oder mehr bedeutet, dass dem Host wahrscheinlich Arbeitsspeicher fehlt, und „Ein Wert für freien Arbeitsspeicher von 6 % oder weniger zeigt an, dass der Host den Speicherbedarf nicht bewältigen kann“, was zur Speicherrückgewinnung führt.

Der Zustand ist ein Wert des Hosts, und einer VM kann Arbeitsspeicher entzogen werden, während der Host high zeigt. KB 374743 beschreibt Hosts mit Swap-in- und Swap-out-Raten über null, geringer Gesamtnutzung des Arbeitsspeichers und dem Zustand high und nennt als Ursache ein konfiguriertes Speicherlimit: ESXi lagert aus, „wenn es die von einer virtuellen Maschine angeforderte Menge an Arbeitsspeicher aufgrund eines eigens konfigurierten Speicherlimits nicht bereitstellen kann.“

Transparent Page Sharing und Salting

ESX kann Speicherseiten mit identischem Inhalt in nur einer Kopie halten, tut das standardmäßig aber nur innerhalb einer VM, eine Voreinstellung, die vSphere 6.0 eingeführt hat und die Patches auch in einige ältere Versionen gebracht haben. Broadcoms KB 323624 erklärt den Mechanismus. Der Salt einer VM ist ohne andere Einstellung ihre eindeutige vc.uuid, und Seiten werden nur zwischen VMs mit demselben Salt geteilt; Sharing zwischen VMs braucht daher einen gemeinsamen Salt je VM oder eine Änderung der Host-Einstellung Mem.ShareForceSalting, deren Standardwert 2 ist. Die Dokumentation zu vSphere 9.1 nennt den Grund: „Aus Sicherheitsgründen ist Transparent Page Sharing zwischen virtuellen Maschinen standardmäßig deaktiviert“.

Sharing zwischen VMs wieder einzuschalten ist eine Sicherheitsentscheidung, die für den ganzen Host gilt. Laut den Best Practices für 9.0 teilt ESX keine großen Seiten, sodass sich auf einem Host, der sie nutzt, Einsparungen unter Umständen erst zeigen, wenn Speicherdruck ESX dazu bringt, große Seiten in kleine aufzuteilen.

Ballooning, Speicherkomprimierung und Host-Swapping

Ballooning arbeitet über vmmemctl, einen Treiber, der mit VMware Tools installiert wird. Setzt ESX ein Ballooning-Ziel, belegt der Treiber Arbeitsspeicher im Gast, sodass das Gastbetriebssystem die Seiten freigibt, die es am wenigsten braucht, und sie bei Bedarf auf seine eigene virtuelle Festplatte auslagert. Deshalb verlangt Broadcom auf überbelegten Hosts einen Swap-Bereich im Gast von mindestens dem konfigurierten Arbeitsspeicher der VM abzüglich ihrer Reservierung. Die Diagrammdokumentation zu vSphere 8.0 nennt den Treiber „entscheidend für die Leistung“ und rät zu prüfen, ob er aktiviert ist. Die VM-Option sched.mem.maxmemctl begrenzt in MB, wie viel Arbeitsspeicher Ballooning einer VM entziehen kann.

Die standardmäßig aktive Speicherkomprimierung kommt vor dem Host-Swapping. Eine zum Auslagern ausgewählte Seite, die sich auf 2 KB oder weniger komprimieren lässt, kommt in einen Komprimierungs-Cache im Arbeitsspeicher statt auf die Festplatte. Die Best Practices erklären, dass „die Latenz der Dekomprimierung viel geringer ist als die Swap-in-Latenz“. Seiten, die sich nicht komprimieren lassen, gehen in die eigene Swap-Datei der VM, ohne Zutun des Gastes.

Die Best Practices für 9.0 raten davon ab, Arbeitsspeicher so weit zu überbelegen, dass Host-Swapping aktive Seiten auslagert, und ebenso davon, die vorgelagerten Techniken abzuschalten: „Da ESX Page Sharing, Ballooning und Speicherkomprimierung nutzt, um den Bedarf an Swapping auf Host-Ebene zu verringern, deaktivieren Sie diese Techniken nicht.“

esxtop-Zähler für den Arbeitsspeicher und vCenter-Diagramme

Drücken Sie in esxtop auf dem Host m für die Speicheransicht. Die Zeilen PMEM, VMKMEM, PSHARE, SWAP, ZIP und MEMCTL fassen den Host zusammen, und jede VM-Zeile trägt die Zähler je VM, alle in MB oder MB pro Sekunde. Spalten, die nicht angezeigt werden, fügen Sie mit f hinzu.

Broadcom TechDocs: Speicheransicht von esxtop (Memory Panel), vSphere 8.0 (16. September 2026) und 9.1 (12. Oktober 2026); KB 438023 (ESXi 8.0) und KB 374743 (ESXi 7.0 und 8.0).

KB 438023 hält fest: „Das Ziel ist dauerhaft null Swap-Aktivität.“ SWCUR allein kann in die Irre führen, da KB 374743 anmerkt, dass ausgelagerte Seiten nach und nach zurückkehren; die Raten zeigen, ob eine VM noch auf Seiten von der Festplatte wartet. Die CPU-Seite desselben Hosts, Ready-Zeit und Co-Stop, behandelt unser Leitfaden zu CPU Ready und dem vCPU-Verhältnis.

In vCenter lesen die Best Practices Ballooned memory (Average) unter Monitor, Performance, Advanced, Memory ab; fehlt Ballooning, deutet das darauf hin, dass ESX nicht unter starkem Speicherdruck steht. Liegt Consumed im selben Diagramm über Active, werten sie das so, dass der Gast „derzeit den gesamten Arbeitsspeicher erhält, den er braucht“. Unter Monitor, Utilization, Guest Memory sind Werte ungleich null bei Swapped und Compressed „ein Zeichen für stärkeren Speicherdruck“. Die Cluster-Zähler Balloon und Consumed werden auf Statistikebene 1 erfasst, Active und Swap Used erst ab Ebene 2.

Unser Infrastruktur-Audit erfasst Hosts, Cluster und ihre tatsächliche Ressourcennutzung anhand der Exporte, die Sie bereitstellen. Schicken Sie uns die esxtop-Speicherzeilen eines Hosts, der Ballooning oder Swapping zeigt, mit den Limits und Reservierungen seiner VMs.

Häufige Ursachen für Ballooning und Swapping

Speicherlimits stehen an erster Stelle, weil sie Swapping auf Hosts mit freiem Arbeitsspeicher verursachen. Ein Limit ist eine VM-Einstellung, sched.mem.max in der .vmx-Datei, und KB 374743 löst den Fall, indem sie es auf Unlimited setzt und die VMX-Datei neu lädt.

Reservierungen wirken in die andere Richtung. Wird der gesamte Arbeitsspeicher einer VM reserviert, entfällt das Host-Swapping für diese VM, doch die Best Practices für 9.0 warnen, dass Reservierungen die Zahl der VMs verringern, die ein System betreiben kann. Die Dokumentation zu vSphere 8.0 rät, eine Reservierung zu senken, die „viel höher als ihr aktiver Arbeitsspeicher“ gesetzt ist, damit der VMkernel ungenutzten Arbeitsspeicher für andere VMs zurückholen kann.

Überdimensionierte VMs blähen den verbrauchten Arbeitsspeicher auf. KB 438023 wertet ein dauerhaft niedriges Verhältnis von aktivem zu zugewiesenem Arbeitsspeicher als Zeichen von Überdimensionierung, und die Best Practices merken an, dass zu viel zugewiesener Arbeitsspeicher den Speicher-Overhead der VM erhöht. Wie Sie überdimensionierte VMs messen und verkleinern, behandelt unser Leitfaden zur Verschwendung in vSphere-Umgebungen.

HA-Failover-Kapazität zeigt ihre Wirkung erst, wenn ein Host ausfällt. Broadcoms Seite zu HA Admission Control für vSphere 8.0 zählt reservierten Arbeitsspeicher und sagt „Der tatsächlich von der virtuellen Maschine verbrauchte Arbeitsspeicher wird bei der Berechnung nicht berücksichtigt“, und wo die Nutzung die Reservierungen übersteigt, ist „nicht genügend Failover-Kapazität verfügbar, was beim Failover zu Leistungseinbußen führt.“ Ein Cluster aus 12 Hosts, der die Admission Control besteht, kann auf den verbleibenden 11 dennoch Ballooning und Swapping zeigen; unser Leitfaden zur Host-Konsolidierung bei Lizenzierung pro Kern dimensioniert Cluster bei Ausfall eines Hosts.

Auf ESX-9-Hosts ergänzt Memory Tiering NVMe-Kapazität hinter dem DRAM. Broadcoms Hinweise für 9.1, aktualisiert am 12. Oktober 2026, halten fest: „Verwenden Sie keine Speicherüberbelegung, wenn Memory Tiering aktiviert ist.“ Sie merken außerdem an, dass der Swap-Code „eine vereinfachte Zufallsauswahl der auszulagernden Seiten verwendet“, während Tiering Seiten nach ihrem Alter in heiß und kalt einteilt. Anforderungen und Sizing stehen in unserem Leitfaden zu vSphere Memory Tiering mit NVMe.

Ballooning und Swapping in vSphere beheben

Arbeiten Sie vom Host zur VM, eine Änderung je Wartungsfenster, damit jeder Schritt seine Wirkung zeigt.

1. Erfassen Sie die langsame Phase in esxtop mit m: den Zustand in der Zeile VMKMEM, MCTLSZ, SWR/s und SWW/s je VM und ob der Host überhaupt Arbeitsspeicher zurückgewinnt.
2. Lagert eine VM auf einem Host im Zustand high aus, prüfen Sie ihr Speicherlimit und setzen Sie es auf Unlimited, sofern ihr Verantwortlicher den Grund dafür nicht bestätigt.
3. Prüfen Sie MCTL? für jede VM und installieren oder reparieren Sie VMware Tools, wo N angezeigt wird.
4. Vergleichen Sie aktiven und verbrauchten Arbeitsspeicher je VM über 30 Tage und verkleinern Sie überdimensionierte VMs schrittweise, wobei jeder Schritt ein Ausschalten erfordert.
5. Senken Sie Reservierungen, die weit über dem aktiven Arbeitsspeicher liegen, und reservieren Sie den vollen Arbeitsspeicher nur für VMs, die nie ausgelagert werden dürfen.
6. Verlagern Sie Last mit DRS oder vMotion auf Hosts mit freiem Arbeitsspeicher, und ergänzen Sie physischen Arbeitsspeicher, wo der aktive Arbeitsspeicher des Clusters bei Ausfall eines Hosts nicht passt.
7. Prüfen Sie das Auslagern im Gast, da KB 438023 aktives Paging im Gast als Zeichen einer für ihre Last unterdimensionierten VM wertet, was der Host nicht sehen kann.

Speicherüberbelegung in der Kapazitätsplanung

Der Arbeitsspeicher bestimmt oft die Zahl der Hosts, die ein Cluster braucht, und er trägt keine VMware-Lizenz, während jeder Host lizenzierte Kerne hinzufügt. Dimensionieren Sie den Cluster so, dass das 95. Perzentil des verbrauchten Arbeitsspeichers auf die Hosts passt, die nach einem Ausfall verbleiben, bei einer Auslastungsobergrenze, die Sie akzeptieren. Die Diagrammwerte von 94 % Nutzung und 6 % freiem Arbeitsspeicher beschreiben einen Host, dem bereits Arbeitsspeicher fehlt, daher gehört die Obergrenze darunter. Behandeln Sie anhaltendes Ballooning oder jedes Swap-in in der monatlichen Spitze als Befund. Die Drei-Jahres-Prognose steht in unserem Leitfaden zur Kapazitätsplanung für vSphere.

Erlauben die Speicherdaten weniger oder größere Hosts, konsolidiert unser Engineering-Partner Vixen.UNO die Cluster im Rahmen der VMware-Optimierung, in vereinbarten Wartungsfenstern mit einem Rollback-Plan. Beschreiben Sie Ihre Cluster und ihren Arbeitsspeicher je Host im Formular unten.

Was wir tun

Bei Speicherproblemen beginnt die VMware-Optimierung mit dem Audit von Umgebung und Lizenzen, in dem das Team unseres Engineering-Partners Vixen.UNO neben Versionen und Abonnements die tatsächliche Ressourcennutzung jedes Hosts und Clusters erfasst. Dasselbe Team stimmt danach Editionen und Abonnements auf Ihre realen Workloads ab und konsolidiert Hosts und Cluster; gibt es nichts zu optimieren, sagen wir das. Eurokommerz hält den Vertrag und liefert Hardware und Lizenzen. Änderungen laufen in vereinbarten Wartungsfenstern, Schritt für Schritt, mit einem Rollback-Plan für jede Etappe, und Support unter einem vereinbarten SLA kann folgen. Unser Infrastruktur-Audit arbeitet mit den Unterlagen und Exporten, die Sie bereitstellen, ohne Zugriff auf Ihre Produktivsysteme. Das erste Gespräch ist kostenlos; der Preis des technischen Assessments steht vor Beginn fest.

FAQ