# Proxmox Memory Optimization: Deep Dive in Ballooning & KSM

TL;DR / Management Summary RAM ist oft die teuerste und knappste Ressource im Cluster. Proxmox bietet zwei mächtige Technologien zur Optimierung: Memory Ballooning (fordert ungenutzten RAM von VMs zurück) und KSM (Kernel Samepage Merging) (findet identische Speicherseiten über verschiedene VMs hinweg und speichert sie nur einmal). Ein Senior Admin nutzt diese Features, um eine höhere VM-Dichte zu erreichen, achtet aber streng darauf, dass schreibintensive Datenbanken von der RAM-Teilung ausgenommen werden.

# 1. Memory Ballooning

Der Gast gibt zurück.

Normalerweise belegt eine VM den gesamten zugewiesenen RAM beim Start.

• Technik: Ein Treiber in der VM (virtio-balloon) bläht sich wie ein Ballon auf, wenn der Host RAM-Mangel hat. Das Gast-OS schiebt dann ungenutzte Daten aus dem RAM.
• Einstellung: VM -> Hardware -> Memory -> Edit.
  • Maximum RAM: z.B. 8 GB.
  • Minimum RAM: z.B. 2 GB.
• Voraussetzung: Der QEMU Guest Agent (Artikel 672) muss installiert sein!

# 2. Kernel Samepage Merging (KSM)

Identische Bits bündeln.

KSM ist ein Hintergrund-Prozess des Proxmox-Hosts.

• Vorgang: Er scannt den RAM aller VMs. Findet er identische Seiten (z.B. den Windows-Kernel von 50 identischen VMs), merkt er sich diese nur einmal und setzt Zeiger für alle anderen VMs.
• Effekt: Sie können 150 GB RAM an VMs versprechen, obwohl physisch nur 128 GB vorhanden sind.
• CPU Last: KSM verbraucht ca. 1-2% CPU für den Scan-Vorgang.

# 3. Deep Dive: Wann welches Feature?

Die Strategie.

# 1. Wann Ballooning nutzen?

• Ideal für Workstations (VDI).
• Ideal für Test-Umgebungen.
• Niemals für SQL-Server oder Java-Apps (diese belegen oft den gesamten RAM als Cache, was Ballooning ineffizient macht).

# 2. Wann KSM nutzen?

• Ideal bei vielen identischen VMs (Templates, Artikel 667).
• Wichtig: KSM wird erst aktiv, wenn der Host-RAM knapp wird.

# 4. Day-2 Operations: RAM-Härtung (Hugepages)

Performance vor Flexibilität.

Für Hochleistungs-Workloads (z.B. SAP HANA oder riesige Datenbanken) deaktivieren wir Ballooning und KSM.

• Aktion: Nutzen Sie Hugepages.
• Technik: Der Kernel reserviert große, zusammenhängende Speicherblöcke (z.B. 1 GB statt 4 KB).
• Vorteil: Reduziert TLB-Misses und beschleunigt den Speicherzugriff um bis zu 10%.

# 5. Troubleshooting & “War Stories”

Wenn der RAM ausgeht.

# Top 3 Fehlerbilder

1. Symptom: VMs werden vom Kernel beendet (“Out of Memory Killer”).

   • Ursache: Zu extremes RAM-Overprovisioning kombiniert mit deaktiviertem KSM oder Ballooning-Hängern.
   • Lösung: Physischen RAM nachrüsten oder max_memory der VMs reduzieren.

2. Symptom: VM zeigt hohen RAM-Verbrauch, obwohl keine App läuft.

   • Ursache: Das Gast-OS nutzt den RAM als Disk-Cache (ZFS/Windows Cache). Ballooning kann diesen Cache oft nicht schnell genug leeren.

3. Symptom: Hohe Latenz in der VM beim Speicherzugriff.

   • Lösung: Prüfen, ob der Host swappt. free -m am Host ausführen. Wenn swap used > 0, ist das System überbucht.

# “War Story”: Der “Swap-of-Death”

Ein Admin vertraute zu sehr auf KSM und startete 100 VMs auf einem Host mit nur 64 GB RAM. Das Ergebnis: Solange die VMs im Leerlauf waren, funktionierte KSM wunderbar und sparte 40 GB RAM. Die Katastrophe: Nach einem Windows-Update-Dienstag neustarteten alle VMs gleichzeitig. Da nach dem Reboot alle Speicherseiten erst einmal individuell geschrieben wurden, konnte KSM sie nicht schnell genug mergen. Die Folge: Der Host begann massiv auf die SSD zu swappen. Die I/O-Last stieg so stark an, dass der Cluster-Heartbeat (Artikel 693) verloren ging und der Host sich selbst rebootete. Lehre: Nutzen Sie KSM als Puffer, nicht als dauerhafte Kapazitäts-Erweiterung für den Standardbetrieb.

# 6. Monitoring & Reporting

Status der Speicher-Ersparnis.

# Dashboard Analyse

Schauen Sie unter Node -> Summary.

• KPI: KSM Sharing. Zeigt an, wie viele GB der Host gerade physisch spart.
• KPI: Memory usage. Sollte dauerhaft unter 80% liegen, um Puffer für Failover zu haben.

# 7. Fazit & Empfehlung

RAM-Optimierung ist die Kunst der gerechten Verteilung.

• Empfehlung: Nutzen Sie Ballooning für alle Linux-Workloads. Linux geht sehr effizient mit dem Rückgeben von Speicher um.
• Wichtig: Deaktivieren Sie Ballooning für Windows Server mit MSSQL, um unberechenbare Performance-Einbrüche zu vermeiden.

# Anhang: Cheatsheet (Memory CLI)

# Referenzen

• Proxmox VE: Memory Management
• RedHat: Kernel Samepage Merging (KSM) Guide
• Linux Foundation: Memory Ballooning explained