# Huge Pages Mastery: RAM-Zugriffe beschleunigen

TL;DR / Management Summary Standardmäßig verwaltet Linux den Arbeitsspeicher in winzigen 4KB-Häppchen (Pages). Bei Servern mit hunderten Gigabyte RAM führt dies zu einer massiven Belastung des Prozessors, da er den Überblick über Millionen von Seiten behalten muss (TLB Misses). Huge Pages (meist 2MB) lösen dieses Problem. Ein Senior Admin muss wissen, wann er Transparent Huge Pages (THP) aktiviert (für die Bequemlichkeit) und wann er sie für Datenbanken (wie Redis oder Oracle) deaktiviert, um Latenz-Spikes durch den Defragmentierer (khugepaged) zu vermeiden.

# 1. Einführung & Architektur

Das Problem mit dem Index.

Der Prozessor speichert die Zuordnung von virtuellem zu physischem RAM im Translation Lookaside Buffer (TLB). Dieser Puffer ist klein.

• 4KB Pages: Millionen Einträge -> TLB läuft über -> CPU muss im langsamen RAM suchen.
• 2MB Huge Pages: 512x weniger Einträge -> Fast jeder Zugriff ist ein TLB-Hit.

# Der Performance-Vorteil (Mermaid)

graph LR
    A[Application: Memory Access] --> B{TLB Check}
    B -->|Hit| C[Direct RAM Access: Fast]
    B -->|Miss| D[Page Table Walk: Slow]
    subgraph "Scenario A: 4KB Pages"
        D -->|Frequent| D
    end
    subgraph "Scenario B: 2MB Huge Pages"
        B -->|Mostly Hit| C
    end

# 2. Transparent Huge Pages (THP)

Die Automatik des Kernels.

THP versucht, im Hintergrund automatisch 4KB Seiten zu 2MB Blöcken zusammenzufassen.

# Status prüfen

cat /sys/kernel/mm/transparent_hugepage/enabled
# [always]: Aktiv, madvise: Nur wenn App es will, never: Aus.

# THP deaktivieren (Empfohlen für viele DBs)

echo "never" | sudo tee /sys/kernel/mm/transparent_hugepage/enabled

# 3. Explizite Huge Pages

Garantierter Platz für High-Performance.

Im Gegensatz zu THP werden explizite Huge Pages beim Booten fest reserviert. Keine Defragmentierung im Betrieb nötig.

# Schritt 1: Seiten reservieren

# Reserviere 1024 Seiten (à 2MB) = 2GB RAM
sudo sysctl -w vm.nr_hugepages=1024

# Schritt 2: Nutzung prüfen

grep -i Huge /proc/meminfo
# Achten Sie auf HugePages_Free und HugePages_Total

# 4. Day-2 Operations: Wann nutze ich was?

Die strategische Entscheidung.

# 5. Troubleshooting & “War Stories”

Wenn der Defragmentierer das System blockiert.

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

Symptom: Redis meldet im Log “WARNING: The TCP backlog setting of 511 cannot be enforced…” und die Latenz steigt alle paar Minuten für Sekundenbruchteile an. Ursache: THP ist aktiv. Wenn Redis ein Snapshot schreibt (Fork), muss der Kernel bei jeder Änderung 2MB statt 4KB kopieren. Der khugepaged Dienst versucht zudem ständig, den RAM zu defragmentieren. Lösung: Deaktivieren Sie THP komplett für Redis-Hosts.

# Story 2: “Das Speicher-Leck durch Fragmentation”

Symptom: free -m zeigt genug freien RAM, aber eine Applikation kann keine Huge Pages reservieren. Ursache: Der RAM ist “zerstückelt”. Es gibt keinen zusammenhängenden Block von 2MB mehr. Lösung: Nutzen Sie echo 1 > /proc/sys/vm/compact_memory, um den Kernel zur Defragmentierung zu zwingen, oder reservieren Sie Huge Pages bereits beim Booten via Kernel-Parameter hugepages=1024.

# 6. Fazit & Empfehlung

• Wahl: Nutzen Sie explizite Huge Pages für Ihre wichtigsten Applikationen (VMs, DBs).
• Wartung: Überwachen Sie HugePages_Rsvd in /proc/meminfo. Wenn reservierte Seiten nie genutzt werden, verschwenden Sie wertvollen RAM.
• Standard: Auf modernen Desktop-Distros ist THP ein Segen, auf Enterprise-Servern oft ein Risiko.

# Anhang: Cheatsheet