# Memory Pressure: Die Mechanik der Speicherbereinigung

TL;DR / Management Summary Was passiert, wenn der Arbeitsspeicher zur Neige geht, aber der OOM-Killer (Artikel 376) noch nicht aktiv werden soll? Der Kernel startet den Memory Reclaim. Er versucht, ungenutzte Caches freizugeben oder inaktive Seiten in den Swap zu schieben. Ein Senior Admin muss die Wasserzeichen (Watermarks) des Kernels verstehen, um zu verhindern, dass das System in den teuren Direct Reclaim (die Applikation wartet auf den Kernel) rutscht.

# 1. Einführung & Architektur

Kswapd vs. Direct Reclaim.

1. kswapd: Ein Hintergrund-Thread, der bei Erreichen des “Low”-Wasserzeichens beginnt, RAM-Seiten vorsorglich zu bereinigen. (Effizient).
2. Direct Reclaim: Wenn der RAM so knapp ist, dass kswapd nicht hinterherkommt, muss der Prozess, der RAM anfordert, selbst aufräumen. Die Applikation pausiert. (Latenz-Albtraum).

# Der Wasserzeichen-Fluss (Mermaid)

graph TD
    A[Free RAM: High] --> B[Normal Operation]
    B -->|RAM decreasing| C{Watermark: Low reached?}
    C -->|Yes| D[Wake up kswapd: Background Reclaim]
    D -->|Success| A
    D -->|RAM still decreasing| E{Watermark: Min reached?}
    E -->|Yes| F[DIRECT RECLAIM: App waits]
    F -->|Fail| G[OOM KILLER]

# 2. Die Wasserzeichen einstellen

Den Puffer vergrößern.

Der wichtigste Parameter ist vm.min_free_kbytes. Er definiert die absolute Untergrenze, ab der nur noch der Kernel selbst Speicher nutzen darf.

# Tuning für High-Speed I/O

# Vergrößert den Puffer, damit kswapd früher aufwacht
# (Empfehlung: 1-3% des RAMs, max 2-4GB)
sudo sysctl -w vm.min_free_kbytes=1048576

# 3. Monitoring: Reclaim-Aktivität

Warten meine Prozesse?

Nutzen Sie PSI (Pressure Stall Information), um den negativen Effekt von Speichermangel zu messen.

# Den Druck ablesen

cat /proc/pressure/memory
# some avg10=2.50 ...
# partial avg10=1.20 ...

• some: Prozesse mussten auf RAM warten, aber nicht alle.
• full: Alle Prozesse standen still, weil der Kernel mit Reclaim/Swapping beschäftigt war.

# 4. Day-2 Operations: Page Scanning

Wo geht die CPU-Zeit hin?

Wenn der Kernel nach freien Seiten sucht, scannt er die Inactive-Liste. Bei massiver Fragmentierung verbraucht dieser Vorgang viel CPU.

# Überwachen der Scan-Aktivität
watch -n 1 "grep pgscan /proc/vmstat"

Steigen die Werte für pgscan_direct schnell an, ist Ihr System in einer kritischen Performance-Falle.

# 5. Troubleshooting & “War Stories”

Wenn der Server bei 50% RAM einfriert.

# Story 1: “Der hängende Video-Server”

Symptom: Ein Stream-Server mit 128GB RAM wird extrem langsam, obwohl free noch 60GB Available anzeigt. top zeigt hohe Last auf allen kswapd Threads. Ursache: Zu viele kleine Dateien im Cache bei hohem vfs_cache_pressure (Artikel 368). Der Kernel verbringt seine Zeit damit, den Inode-Cache zu scannen, findet aber keine Seiten, die er löschen darf. Lösung: Erhöhen Sie vm.min_free_kbytes, um dem Kernel mehr Spielraum für die Bereinigung zu geben, und reduzieren Sie vfs_cache_pressure temporär.

# Story 2: “Das Fragmentierungs-Loch”

Symptom: Eine Datenbank will 1GB Huge-Pages (Artikel 388) reservieren, aber der Befehl schlägt fehl, obwohl massiv RAM frei ist. Ursache: Memory Fragmentation. Der RAM ist wie ein Schweizer Käse: Es gibt genug Platz, aber kein zusammenhängendes 1GB Stück. Lösung: Nutzen Sie echo 1 > /proc/sys/vm/compact_memory. Der Kernel versucht dann, alle belegten Seiten zusammenzuschieben, um große Lücken zu schließen.

# 6. Fazit & Empfehlung

• KPI: Überwachen Sie pgscan_direct. Es ist der beste Indikator für einen überlasteten Speicher-Stack.
• Performance: Setzen Sie vm.min_free_kbytes bei Servern mit > 64GB RAM auf mindestens 1GB.
• Wartung: Nutzen Sie Zram (Artikel 216), um den Druck auf den Reclaim-Mechanismus durch Kompression zu mindern.

# Anhang: Cheatsheet