Memory-Ballooning

[milkyway]

Hi Zusammen,

ich suche eine Möglichkeit, für eine einzelne VM das Memory-Ballooning abzuschalten.

Gibt es da was?!

Danke & LG,
Milky

[kastlr]

Hallo,

probier mal das.
Disabling Balloon Driver

Viel Erfolg,
Ralf

[Tschoergez]

...oder den balloontreiber bei der installation der VMware-tools nicht mitinstallieren.

... oder ne entsprechend hohe Memory-Reservation für die VM setzen.

Hat aber alles Seiteneffekte (im schlimmsten Fall fängt der ESX bei der VM früher an zu swappen...).

Ich hoffe, Du weißt, was Du tust (siehe auch den Resource Management Guide von VMware) und warum Du das machen willst...

viele grüße,
jörg

[Saturnous]

Es gibt genügend Szenarien wo der Balooning Treiber eher stört als hilft, und im übrigen geht der KB bei W2k8 R2 vor die Wand.

Oracle, MS SQL bringen AWE Unterstützung mit und stolpern eher über das Balooning. W2k8 bringt eigene Mechanismen mit Speicherseiten in möglichst niedrigen Bereichen abzulegen, dem hauseigenen Hypervisor geschuldet. VDI Maschinen lässt man lieber ohne Balooning per Policy am Wochenende runterfahren statt suspenden und schwupps verhindert man lästige Kettenreaktionen weil eine ausgerollte Policy then User.dat Registry Hive neuschreibt (und damit der volsnap Seiten anfordert). Seit x64 SP2 funktioniert bei "W2k3 das Trimming WorkingSets so prächtig das sich Seiten nicht fragmentieren.

Balooning kann schon mal WAN replizierte Storage in die Knie zwingen (mir glaubt ja keiner das es 0 Sinn macht Systemlaufwerke auf synchron replizierten LUNs zu lassen, async reicht für die 100% aus - alles was da überraschend sich ändert ist nach reboot Datenmüll oder liegt in VSS Instanzen (RegDB Writer)).

Früher beschimpfte man die ganzen Memory Defragmentierer Schlangenoelsoftware .. naja wegen Hypervisor machen die schon etwas mehr Sinn, nur ist es unötiger Ballast wenn der Memory-Footprint des OS selbst ins Pagefile gedrückt wird - also den Parameter kann man um gewisse Freezes zu verhindern auf 280 MB (W2k3 - pi mal daumen wert) stellen.

[Tschoergez]

Du sprichst über den Balloon-Treiber von VMware ??

Der dient doch hauptsächlich dazu, dem vmkernel die Speicherseiten "zu zeigen",die vom Gast-OS nicht mehr in Verwendung sind. Fragmentierung (oder besser Defragmentierung) spielt dabei keine Rolle...

Negative Auswirkungen hat das erst, wenn das Gast-OS durch den Balloontreiber anfängt zu swappen (dann kommen natürlich auch die Nachteile bei der Replikation des Storage, auf dem das pagefile liegt, zum Tragen (gleiches gilt auch für den Storage, auf dem .vswp-Dateien liegen).

Alles in allem sollte man eher darauf achten, seine VMs passend zu sizen, d.h. soviel (und nur soviel) RAM "einbauen", wie die VM gerne benötigen. Gerade SQL&Co. nehmen ganz gern allen Speicher, den sie sehen, fürs cachen (auch wenns nicht wirklich notwendig wäre), und das sorgt dann natürlich für ungewünschte Seiteneffekte, wenn der ESX den balloontreiber aktiviert in der VM.

Viele Grüße,
Jörg

[milkyway]

Es gibt genügend Szenarien wo der Balooning Treiber eher stört als hilft, und im übrigen geht der KB bei W2k8 R2 vor die Wand.

Oracle, MS SQL bringen AWE Unterstützung mit und stolpern eher über das Balooning. W2k8 bringt eigene Mechanismen mit Speicherseiten in möglichst niedrigen Bereichen abzulegen, dem hauseigenen Hypervisor geschuldet. VDI Maschinen lässt man lieber ohne Balooning per Policy am Wochenende runterfahren statt suspenden und schwupps verhindert man lästige Kettenreaktionen weil eine ausgerollte Policy then User.dat Registry Hive neuschreibt (und damit der volsnap Seiten anfordert). Seit x64 SP2 funktioniert bei "W2k3 das Trimming WorkingSets so prächtig das sich Seiten nicht fragmentieren.

Balooning kann schon mal WAN replizierte Storage in die Knie zwingen (mir glaubt ja keiner das es 0 Sinn macht Systemlaufwerke auf synchron replizierten LUNs zu lassen, async reicht für die 100% aus - alles was da überraschend sich ändert ist nach reboot Datenmüll oder liegt in VSS Instanzen (RegDB Writer)).

Früher beschimpfte man die ganzen Memory Defragmentierer Schlangenoelsoftware .. naja wegen Hypervisor machen die schon etwas mehr Sinn, nur ist es unötiger Ballast wenn der Memory-Footprint des OS selbst ins Pagefile gedrückt wird - also den Parameter kann man um gewisse Freezes zu verhindern auf 280 MB (W2k3 - pi mal daumen wert) stellen.

Ich hätte es besser nicht sagen können

Wir haben zwei ESXi-Hosts mit 64 GB RAM und 4 CPUs. Alle laufen fast bis zum Anschlag. von den vielen virtuellen Maschinen sind auf jedem Host mind. 2 SQL-Server vorhanden, die mehrere TB untereinander synchen ... Daher muss der Ballooning Treiber weg