Memory Managment

Warum ist Memory Management bei Virtualisierung wichtig?

RAM ist eine der kritischsten Ressourcen in einer virtualisierten Umgebung. Anders als bei der CPU wo kurze Wartezeiten tolerierbar sind kann ein Mangel an Arbeitsspeicher eine VM komplett zum Stillstand bringen. Ein gutes Verständnis des Memory Managements ist deshalb für jeden Systemintegrator unverzichtbar.

Der Hypervisor muss den verfügbaren physischen RAM intelligent auf alle laufenden VMs verteilen – und dabei sowohl Performance als auch Effizienz im Blick behalten.

Physischer RAM vs. virtueller RAM

Memory Overcommitment

Wie bei der CPU kann auch RAM überbucht werden – Memory Overcommitment bedeutet dass mehr vRAM vergeben wird als physisch vorhanden ist:

Physischer RAM: 128 GB

VM 1:  32 GB vRAM
VM 2:  32 GB vRAM
VM 3:  32 GB vRAM
VM 4:  32 GB vRAM
VM 5:  16 GB vRAM
       ──────────
Total: 144 GB vRAM auf 128 GB physisch → Overcommitment

Funktioniert weil VMs selten ihren gesamten RAM gleichzeitig nutzen.

Memory Overcommitment ist aber riskanter als CPU-Overcommitment: Wenn mehrere VMs gleichzeitig viel RAM benötigen muss der Hypervisor aktiv eingreifen – mit verschiedenen Techniken.

Memory-Management-Techniken des Hypervisors

1. Transparent Page Sharing (TPS)

Der Hypervisor sucht nach identischen Speicherseiten (4 KB Blöcke) in verschiedenen VMs und konsolidiert diese zu einer einzigen physischen Kopie:

VM 1: Windows Server 2022
VM 2: Windows Server 2022

Beide VMs haben identische Kernel-Seiten im RAM:
Ohne TPS: 2 × 512 MB Kernel = 1.024 MB physischer RAM belegt
Mit TPS:  1 × 512 MB Kernel = 512 MB physischer RAM belegt
          → 512 MB gespart!

Bei Schreibzugriff: Copy-on-Write
→ Die geteilte Seite wird kopiert bevor sie verändert wird

TPS funktioniert am besten wenn viele VMs mit demselben Betriebssystem laufen. Bei modernen Betriebssystemen mit ASLR (Address Space Layout Randomization) ist die Effizienz gesunken.

2. Memory Ballooning

Ein spezieller Treiber (Balloon Driver) wird in jeder VM installiert. Wenn der Hypervisor RAM zurückgewinnen möchte "bläst er den Ballon auf" – der Treiber reserviert RAM innerhalb der VM sodass das Gast-OS anderen Prozessen weniger RAM zur Verfügung stellt:

Normaler Zustand:
VM hat 16 GB zugewiesen, nutzt 12 GB aktiv
Balloon Driver: inaktiv (0 GB reserviert)

Hypervisor braucht RAM zurück:
Balloon Driver bläst auf: reserviert 4 GB innerhalb der VM
→ VM-OS muss Prozesse auslagern (Swapping)
→ Hypervisor bekommt 4 GB physischen RAM zurück

Vorteile:
✓ VM-OS entscheidet selbst welche Seiten ausgelagert werden
✓ Effizienter als blindes Auslagern durch den Hypervisor

Voraussetzung:
✓ VMware Tools / Hyper-V Integration Services installiert

3. Memory Swapping (Hypervisor-Swap)

Als letztes Mittel lagert der Hypervisor RAM-Seiten einer VM auf die Festplatte aus – in eine Swap-Datei:

VMware ESXi:  .vswp-Datei pro VM
Hyper-V:      Smart Paging File
Proxmox/KVM:  Host-Swap

Performance-Auswirkung: ERHEBLICH
RAM-Zugriff:  ~100 ns
SSD-Zugriff:  ~100.000 ns (1.000× langsamer)
HDD-Zugriff:  ~10.000.000 ns (100.000× langsamer)

→ Hypervisor-Swap sollte immer vermieden werden!

4. Memory Compression

Bevor der Hypervisor auf Festplatten-Swap zurückgreift versucht er RAM-Seiten zu komprimieren und in einem Komprimierungs-Cache zu halten:

Ablauf (VMware ESXi):
1. TPS – identische Seiten zusammenführen
2. Ballooning – RAM von VMs zurückfordern
3. Compression – Seiten komprimieren (Cache im RAM)
4. Swap – Seiten auf Disk auslagern (letzter Ausweg)

Kompression:
→ Typisch 2:1 Kompressionsrate
→ Zugriff viel schneller als Disk-Swap
→ Kostet CPU-Zeit für Komprimierung/Dekomprimierung

Dynamic Memory (Hyper-V)

Microsoft Hyper-V hat eine eigene Implementierung namens Dynamic Memory. Statt fester RAM-Zuweisung arbeitet Hyper-V mit Grenzen:

Beispiel Dynamic Memory:
VM startet mit 2 GB
Anwendung benötigt mehr RAM:
→ Hyper-V gibt bis zu 16 GB (Maximum) dynamisch zu
Anwendung braucht weniger:
→ Hyper-V holt RAM zurück (Minimum: 512 MB)

NUMA und Memory Management

Bei Multi-Socket-Servern ist es wichtig dass VM-RAM aus dem gleichen NUMA-Knoten wie die vCPUs der VM stammt:

Optimale Konfiguration (NUMA-bewusst):
Socket 0: CPU 0-7 + RAM Bank 0 (64 GB)
  └── VM 1: vCPUs von Socket 0, RAM von Bank 0 ✓

Schlechte Konfiguration (NUMA-übergreifend):
Socket 0: CPU 0-7
Socket 1: RAM Bank 1
  └── VM 1: vCPUs von Socket 0, RAM von Bank 1 ✗
            → Remote-Speicherzugriffe = höhere Latenz

Huge Pages / Large Pages

Standardmäßig verwaltet ein System RAM in 4 KB großen Seiten. Huge Pages (Linux) bzw. Large Pages (Windows) verwenden 2 MB große Seiten:

Praxisempfehlungen

Zusammenfassung

• Memory Overcommitment vergibt mehr vRAM als physisch vorhanden – riskanter als CPU-Overcommitment

• TPS (Transparent Page Sharing) konsolidiert identische Speicherseiten verschiedener VMs

• Ballooning fordert RAM von VMs zurück über einen Treiber im Gast-OS

• Memory Compression komprimiert Seiten bevor auf Disk-Swap zurückgegriffen wird

• Hypervisor-Swap ist das letzte Mittel und erheblich langsamer als RAM

• Hyper-V Dynamic Memory passt RAM-Zuweisung dynamisch zwischen Minimum und Maximum an

• NUMA-bewusstes Memory Management verhindert langsame Remote-Speicherzugriffe

• Huge Pages verbessern Performance bei großen Workloads wie Datenbanken