Transparent Huge Pages vs. explizite Huge Pages: Unterschiede und Tuning für Datenbankserver

1. Speicherseiten Grundlagen: Warum größere Seiten überhaupt helfen

Der Kernel verwaltet physischen Arbeitsspeicher in Seiten fester Größe, standardmäßig 4 Kilobyte auf x86_64 Systemen. Jeder Zugriff eines Prozesses auf virtuellen Speicher muss über die Memory Management Unit der CPU in eine physische Adresse übersetzt werden, wofür der sogenannte Translation Lookaside Buffer, kurz TLB, als schneller Cache für kürzlich genutzte Adressübersetzungen dient.

Bei Anwendungen mit sehr großem Speicherbedarf, etwa einem Datenbank Puffer Pool von mehreren Dutzend Gigabyte, reicht die begrenzte Anzahl an TLB Einträgen bei 4 Kilobyte Seiten nicht aus, um den gesamten aktiven Speicherbereich abzudecken, was zu häufigen TLB Misses und damit zusätzlichen, langsameren Seitentabellen Lookups führt. Größere Seiten, etwa 2 Megabyte, reduzieren die Anzahl benötigter TLB Einträge für denselben Speicherbereich um den Faktor 512 und senken dadurch spürbar die Zahl an TLB Misses.

2. Explizite Huge Pages über HugeTLB

HugeTLB Huge Pages werden beim Systemstart oder zur Laufzeit als feste Anzahl aus dem verfügbaren Arbeitsspeicher reserviert und stehen ab diesem Moment exklusiv für Anwendungen zur Verfügung, die sie explizit über die shmget Systemaufrufe mit dem Flag SHM_HUGETLB oder über ein gemountetes hugetlbfs Dateisystem anfordern. Diese Reservierung ist statisch: Einmal reservierter Huge Page Speicher steht anderen, nicht Huge Page fähigen Anwendungen nicht mehr zur Verfügung, selbst wenn er gerade ungenutzt ist.

Der große Vorteil dieser Statik ist Vorhersagbarkeit: Einmal erfolgreich reserviert, bleiben die Seiten über die gesamte Laufzeit stabil im Speicher, ohne dass der Kernel im Hintergrund Seiten zusammenlegen, aufteilen oder verschieben muss. Nachteilig ist der administrative Aufwand, weil die passende Anzahl an Huge Pages vorab kalkuliert und über /proc/sys/vm/nr_hugepages oder einen Kernel Parameter beim Boot reserviert werden muss, was bei falscher Dimensionierung entweder Speicher verschwendet oder nicht ausreicht.

# Aktuellen Huge Page Status prüfen
grep Huge /proc/meminfo

# 4096 Huge Pages a 2 MB dauerhaft reservieren (entspricht 8 GB)
echo 4096 | sudo tee /proc/sys/vm/nr_hugepages

# Dauerhaft über sysctl.conf für zukünftige Boots festlegen
echo "vm.nr_hugepages = 4096" | sudo tee -a /etc/sysctl.d/99-hugepages.conf

3. Wie Transparent Huge Pages automatisch arbeiten

Transparent Huge Pages, kurz THP, verfolgen einen fundamental anderen Ansatz: Statt einer expliziten Reservierung durch die Anwendung überwacht der Kernel Thread khugepaged laufend den Speicherbereich aller Prozesse und legt im Hintergrund automatisch mehrere zusammenhängende 4 Kilobyte Seiten zu einer 2 Megabyte Huge Page zusammen, sobald er eine geeignete, hinreichend zusammenhängende Region findet, ohne dass die Anwendung selbst davon etwas mitbekommt.

Dieser Automatismus funktioniert bewusst transparent, also ohne Codeänderung an der jeweiligen Anwendung, was THP auf den ersten Blick attraktiv macht. Der entscheidende Unterschied zu HugeTLB liegt aber genau in dieser Automatik: Der Kernel muss dafür fortlaufend Speicherbereiche analysieren, gegebenenfalls per Memory Compaction fragmentierten Speicher defragmentieren, um überhaupt zusammenhängende 2 Megabyte Blöcke bilden zu können, und diese Arbeit passiert im laufenden Betrieb, nicht einmalig beim Systemstart.

# Aktuellen THP Status und Modus anzeigen
cat /sys/kernel/mm/transparent_hugepage/enabled
# Ausgabe zeigt z.B.: always [madvise] never

# khugepaged Aktivität im laufenden Betrieb beobachten
cat /sys/kernel/mm/transparent_hugepage/khugepaged/pages_collapsed

4. Warum THP bei Datenbanken zu Latenz Spitzen führt

Das eigentliche Problem entsteht immer dann, wenn khugepaged auf stark fragmentiertem Speicher aktiv wird: Um eine zusammenhängende 2 Megabyte Region zu erhalten, muss der Kernel bestehende Seiten per Memory Compaction verschieben, was CPU Zeit kostet und in ungünstigen Fällen den zugreifenden Prozess für die Dauer der Operation blockiert. Bei einem MySQL Server mit großem InnoDB Puffer Pool äußert sich das als plötzliche, scheinbar grundlose Latenz Spitze mitten im Normalbetrieb, ohne erkennbaren äußeren Auslöser.

Zusätzlich verschärft der Modus always das Problem, weil der Kernel dann für praktisch jeden anonymen Speicherbereich versucht, Huge Pages zu bilden, unabhängig davon, ob die jeweilige Anwendung davon überhaupt profitiert. Bei Workloads mit vielen kleinen, kurzlebigen Allokationen, wie sie in Redis bei häufigem Key Churn vorkommen, führt das eher zu zusätzlichem Overhead durch ständiges Zusammenlegen und Aufsplitten von Seiten als zu einem tatsächlichen Performance Gewinn.

5. THP Status und Modus über sysfs prüfen

Der aktuelle THP Modus lässt sich unter /sys/kernel/mm/transparent_hugepage/enabled auslesen, wobei drei Werte möglich sind: always aktiviert THP für jeden geeigneten Speicherbereich automatisch, madvise bildet Huge Pages nur dort, wo eine Anwendung dies explizit über den Systemaufruf madvise mit dem Flag MADV_HUGEPAGE anfordert, und never deaktiviert THP vollständig.

Zusätzlich zum reinen Enabled Status lohnt sich ein Blick auf /sys/kernel/mm/transparent_hugepage/defrag, das steuert, wie aggressiv der Kernel bei fehlendem zusammenhängendem Speicher per Compaction nachhilft. Ein Wert von defer+madvise verschiebt die aufwendige Defragmentierung auf einen Hintergrund Kthread statt sie synchron im Zugriffspfad der Anwendung auszuführen, was viele der schlimmsten Latenz Spitzen bereits deutlich abmildert, ohne THP vollständig abzuschalten.

# THP Enabled Modus und Defrag Verhalten gemeinsam prüfen
cat /sys/kernel/mm/transparent_hugepage/enabled
cat /sys/kernel/mm/transparent_hugepage/defrag

# Aktuell durch THP belegte anonyme Huge Pages im laufenden System
grep AnonHugePages /proc/meminfo

6. THP für MySQL und Redis deaktivieren

Sowohl der MySQL als auch der Redis Betreiber Dokumentation empfehlen übereinstimmend, THP auf Servern mit diesen Diensten auf never zu setzen, weil beide Workloads typischerweise große, langlebige Speicherbereiche mit unregelmäßigem Zugriffsmuster verwalten, bei denen der khugepaged Automatismus mehr Schaden durch Latenz Spitzen anrichtet, als er an TLB Miss Reduktion einbringt.

Eine Änderung über echo never in die sysfs Datei wirkt sofort, überlebt aber keinen Reboot, weshalb die Einstellung dauerhaft über einen systemd Service, einen rc.local Eintrag oder einen Kernel Parameter beim Boot abgesichert werden muss. Der zuverlässigste Weg auf modernen Systemen ist ein dedizierter systemd Oneshot Service, der bei jedem Boot automatisch ausgeführt wird, statt sich auf ein manuell gepflegtes Init Skript zu verlassen.

# /etc/systemd/system/disable-thp.service
cat <<'EOF' | sudo tee /etc/systemd/system/disable-thp.service
[Unit]
Description=Disable Transparent Huge Pages (THP)
After=sysinit.target local-fs.target
Before=mysql.service redis.service

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/enabled'
ExecStart=/bin/sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/defrag'

[Install]
WantedBy=basic.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now disable-thp.service

7. Explizite Huge Pages als Alternative für den InnoDB Puffer Pool

Wo THP durch die abgeschaltete Automatik keinen Beitrag mehr leistet, kann MySQL trotzdem von großen Seiten profitieren, allerdings über den entgegengesetzten, expliziten Weg: Mit der Option large-pages in der MySQL Konfiguration und vorab über nr_hugepages reserviertem HugeTLB Speicher legt InnoDB seinen Puffer Pool gezielt in stabilen, nicht auslagerbaren Huge Pages ab, ohne dass der Kernel im laufenden Betrieb noch etwas an dieser Zuordnung ändern könnte.

Diese explizite Variante erfordert etwas mehr Vorplanung, weil die Anzahl reservierter Huge Pages zur tatsächlichen Puffer Pool Größe passen muss und der reservierte Speicher für andere Anwendungen blockiert bleibt, liefert dafür aber ein deutlich vorhersehbareres Verhalten ohne jegliches Risiko von Compaction bedingten Latenz Spitzen, wie sie bei THP im laufenden Betrieb auftreten können.

8. Monitoring: Woran erkenne ich THP bedingte Latenz Probleme?

Ein zuverlässiger erster Indikator ist ein Anstieg der Werte compact_stall und thp_collapse_alloc in /proc/vmstat, die jeweils zeigen, wie oft ein Prozess auf eine laufende Memory Compaction Operation warten musste beziehungsweise wie oft khugepaged tatsächlich Seiten zusammengelegt hat. Ein kontinuierlich steigender compact_stall Wert bei gleichzeitig auftretenden, unregelmäßigen Latenz Spitzen in der Anwendung ist ein starkes Indiz für THP als Ursache.

Ergänzend liefert perf stat mit dem Event page-faults sowie ein direkter Blick auf AnonHugePages in /proc/meminfo über die Zeit ein klareres Bild, ob und wie stark THP auf einem bestimmten Server tatsächlich aktiv ist, statt sich allein auf die statische Konfiguration unter sysfs zu verlassen, die keine Aussage über die tatsächliche Laufzeit Aktivität von khugepaged trifft.

# Compaction Stalls und THP Collapse Ereignisse über die Zeit beobachten
watch -n 2 "grep -E 'compact_stall|thp_collapse_alloc' /proc/vmstat"

# Aktuell durch THP belegte Speichermenge
grep AnonHugePages /proc/meminfo

9. Best Practice Checkliste für Datenbank und Cache Server

Auf jedem Server, der MySQL, MariaDB, PostgreSQL oder Redis produktiv betreibt, gehört THP über einen dauerhaften systemd Service auf never gesetzt, statt sich auf die jeweilige Distributions Voreinstellung zu verlassen, die auf vielen Systemen weiterhin madvise oder sogar always als Standard mitbringt.

Wo der zusätzliche TLB Nutzen großer Seiten dennoch gewünscht ist, etwa für einen sehr großen InnoDB Puffer Pool, führt der Weg über explizite HugeTLB Huge Pages mit sorgfältig kalkulierter nr_hugepages Reservierung, nicht über eine Reaktivierung von THP, weil nur die explizite Variante das Latenz Risiko der Kernel Automatik konsequent vermeidet.

10. Zusammenfassung

11. FAQ: THP vs. Huge Pages