# Page Cache mastery: Warum Linux keinen ‘freien’ RAM mag

TL;DR / Management Summary Ein Senior Admin gerät nicht in Panik, wenn free -m fast null MB freien Speicher anzeigt. Er weiß: Linux nutzt jedes freie Byte als Page Cache, um langsame Festplatten-Zugriffe durch extrem schnelle RAM-Lesezugriffe zu ersetzen. In diesem Modul lernen wir die Architektur des Page Caches kennen, verstehen den Unterschied zum alten Buffer Cache und erfahren, wie wir den Cache kontrollieren können, ohne die Systemstabilität zu gefährden.

# 1. Einführung & Architektur

Alles ist eine Seite.

Der Kernel arbeitet im Speicher mit “Pages” (meist 4KB).

• Page Cache: Speichert Inhalte von Dateien. Wenn Sie cat file.txt zweimal aufrufen, kommt der zweite Aufruf aus dem RAM.
• Buffer Cache: Speichert rohe Disk-Blöcke (Metadaten, Dateisystem-Strukturen). Heute ist er technologisch in den Page Cache integriert.

# Die Caching-Logik (Mermaid)

graph LR
    A[Application: Read Request] --> B{Kernel: Check RAM}
    B -->|Cache Hit| C[Return Data from RAM: ~100ns]
    B -->|Cache Miss| D[Read from SSD/HDD: ~100us - 10ms]
    D --> E[Store in Page Cache]
    E --> C
    subgraph "The 'Used' RAM Trap"
        F[Application RAM]
        G[Page Cache]
        H[Free RAM]
    end

# 2. Den Cache überwachen

Transparenz im Speicher.

Nutzen Sie cat /proc/meminfo, um die Wahrheit zu sehen:

grep -E "Cached|Buffers" /proc/meminfo
# Cached: Die Größe des Page Caches.
# Dirty: Daten im Cache, die noch nicht auf Disk geschrieben wurden.

# Pro-Tipp: pcstat

Es gibt Tools (wie pcstat), die Ihnen anzeigen, welche spezifische Datei gerade zu wie viel Prozent im RAM liegt.

# 3. Manuelle Intervention: Drop Caches

Den Reset-Knopf drücken (mit Vorsicht).

Manchmal (z.B. für Benchmarks) müssen wir den Cache leeren.

# 1. Page Cache leeren
echo 1 | sudo tee /proc/sys/vm/drop_caches

# 2. Inodes und Dentries leeren
echo 2 | sudo tee /proc/sys/vm/drop_caches

# 3. Alles leeren
echo 3 | sudo tee /proc/sys/vm/drop_caches

# 4. Day-2 Operations: Cache-Preloading

Daten bereitstellen, bevor sie gebraucht werden.

Wenn Sie wissen, dass ein Backup oder eine Datenbankabfrage gleich startet, können Sie die Dateien in den Cache “zwingen”.

# Liest die Datei und wirft sie weg (bleibt aber im Page Cache)
cat large_database.db > /dev/null

# 5. Troubleshooting & “War Stories”

Wenn der Cache den OOM-Killer triggert.

# Story 1: “Der hängende ‘Drop Caches’”

Symptom: Der Befehl echo 3 > /proc/sys/vm/drop_caches bleibt für Sekunden hängen und der Server reagiert nicht. Ursache: Der Kernel muss vor dem Leeren des Caches alle “Dirty Pages” auf die Disk schreiben (sync). Wenn die Disk langsam ist, blockiert der Prozess. Lösung: Führen Sie immer erst ein manuelles sync aus, bevor Sie die Caches droppen.

# Story 2: “Das Backup-Problem”

Symptom: Nach dem nächtlichen Backup ist der Webserver für den ersten User extrem langsam. Ursache: Das Backup hat hunderte GB an Daten gelesen und dabei die Webserver-Dateien aus dem Page Cache verdrängt (Cache Eviction). Lösung: Nutzen Sie fadvise (posix_fadvise), um dem Kernel zu sagen, dass das Backup-Programm die Daten nicht cachen soll (POSIX_FADV_DONTNEED).

# 6. Fazit & Empfehlung

• Verständnis: “Cached RAM” ist guter RAM. Er steht Applikationen sofort zur Verfügung, wenn sie ihn brauchen.
• Performance: Wenn Ihr System bei wiederholten Aufgaben schneller wird, ist der Page Cache Ihr Freund.
• Wartung: Nutzen Sie vmtouch, um wichtige Files (z.B. Shared Libraries) permanent im RAM zu sperren (Locking).

# Anhang: Cheatsheet