# VM Management: Den RAM-Hunger des Kernels steuern

TL;DR / Management Summary Arbeitsspeicher ist die wertvollste Ressource Ihres Servers. Der Kernel verwaltet diesen über das Virtual Memory (VM) Subsystem. Ein Senior Admin verlässt sich nicht auf die Standardwerte, sondern passt das Verhalten an den Workload an: Er steuert mit Swappiness, wann Daten auf die Disk ausgelagert werden, optimiert den VFS-Cache-Druck, um Inodes im RAM zu halten, und konfiguriert Dirty Ratios, um Schreib-Hänger bei massiven I/O-Lasten zu vermeiden.

# 1. Einführung & Architektur

Die Logik hinter dem RAM.

Linux teilt den Speicher in verschiedene Bereiche ein.

• Active/Inactive Memory: Daten, die häufig oder selten genutzt werden.
• Page Cache: Kopien von Dateien von der Disk im RAM.
• Dirty Pages: Daten im RAM, die noch nicht auf die Disk geschrieben wurden.

# Die Speicher-Hebel (Mermaid)

graph TD
    A[Total RAM] --> B[Allocated to Apps]
    A --> C[Page Cache: Disk Buffers]
    C --> D{Free RAM is low?}
    D -->|Option 1: Drop Cache| E[vm.vfs_cache_pressure]
    D -->|Option 2: Swap| F[vm.swappiness]
    G[Write Operation] --> H[Dirty Pages in RAM]
    H -->|Threshold reached| I[Flush to Disk: pdflush]
    I --- J[vm.dirty_ratio]

# 2. Der Klassiker: Swappiness

Wann geht es auf die Platte?

Der Wert vm.swappiness (0-100) definiert, wie aggressiv der Kernel RAM-Seiten gegen Swap-Platz tauscht.

• Desktop: 60 (Standard).
• Server: 10 bis 20. Wir wollen den RAM so lange wie möglich für Applikationen nutzen.
• Datenbanken: Oft 1 (Swap nur im absoluten Notfall vermeiden).

# Temporär setzen
sudo sysctl -w vm.swappiness=10

# 3. VFS Cache Pressure

Metadaten im RAM halten.

Wenn Ihr Server Millionen kleiner Dateien verwaltet (z.B. ein Mailserver oder Webserver), ist der Cache für Inodes und Verzeichnisse kritisch.

• Standard (100): Kernel löscht Inode-Caches genauso oft wie Page-Caches.
• Empfehlung (50): Bevorzugt das Behalten von Dateisystem-Metadaten im RAM.

# In /etc/sysctl.d/99-memory.conf
vm.vfs_cache_pressure = 50

# 4. Day-2 Operations: Dirty Pages & I/O Hänger

Den ‘Write-Freeze’ verhindern.

Wenn eine Applikation GB-weise Daten schreibt, füllt sich der RAM mit “Dirty Pages”. Wenn ein Schwellwert erreicht wird, blockiert der Kernel alle Schreibvorgänge, bis die Disk alles abgearbeitet hat.

# Tuning für langsame Disks

# Beginne mit dem Schreiben im Hintergrund bei 5% RAM Belegung
vm.dirty_background_ratio = 5
# Blockiere Prozesse erst bei 10% (statt Standard 20%)
vm.dirty_ratio = 10

• Vorteil: Die Last wird gleichmäßiger verteilt, statt plötzlicher 30-sekündiger Pausen.

# 5. Troubleshooting & “War Stories”

Wenn der OOM-Killer Amok läuft.

# Story 1: “Der hängende Server bei 80% RAM”

Symptom: Ein SLES-Server wird extrem träge, obwohl free noch 20% Platz anzeigt. top zeigt hohe CPU-Last im System-Bereich (%sy). Ursache: Zu viele Inodes im RAM bei hohem vfs_cache_pressure. Der Kernel verbringt seine gesamte Zeit damit, Cache-Seiten zu suchen und zu löschen. Lösung: Erhöhen Sie den vfs_cache_pressure auf 200, um den Kernel anzuweisen, Metadaten-Caches aggressiver freizugeben.

# Story 2: “Overcommit-Crash”

Symptom: Eine Applikation fordert RAM an und stürzt sofort mit “Out of Memory” ab, obwohl laut Monitoring noch hunderte MB frei sind. Ursache: vm.overcommit_memory steht auf 2 (Don’t overcommit). Der Kernel erlaubt keine Reservierung über das physische Limit hinaus. Lösung: Wenn Ihre Applikation viel RAM reserviert, den sie nie nutzt (typisch für Java/Redis), nutzen Sie vm.overcommit_memory = 0 (Heuristic).

# 6. Fazit & Empfehlung

• Server: Setzen Sie swappiness auf 10.
• I/O: Nutzen Sie niedrige dirty_ratios bei langsamen HDDs oder instabilem Netzwerk-Storage.
• Hugepages: Nutzen Sie für große Datenbanken (Oracle, Postgres) immer Transparent Hugepages oder explizite Hugepages (Artikel 118).

# Anhang: Cheatsheet