Huge Pages fuer MySQL unter Linux einsetzen

1. Warum Huge Pages fuer grosse Buffer Pools relevant sind

Der Linux-Kernel verwaltet Arbeitsspeicher standardmaessig in Seiten (Pages) von 4 Kilobyte Groesse. Fuer einen InnoDB Buffer Pool von 32 Gigabyte bedeutet das theoretisch mehr als acht Millionen einzelne Page-Table-Eintraege, die die CPU-MMU (Memory Management Unit) verwalten und im Translation Lookaside Buffer (TLB) zwischenspeichern muss. Der TLB hat aber nur Platz fuer wenige tausend Eintraege, weshalb bei so vielen kleinen Seiten staendig TLB-Misses auftreten, die jeweils einen zusaetzlichen, langsameren Speicherzugriff auf die Page-Tabelle im RAM erzwingen.

Huge Pages loesen dieses Problem, indem sie Speicher in deutlich groesseren Bloecken verwalten, unter x86_64 typischerweise 2 Megabyte statt 4 Kilobyte pro Seite. Fuer denselben 32-Gigabyte-Buffer-Pool reduziert sich die Anzahl der Page-Table-Eintraege dadurch auf etwa 16.000, was drastisch weniger TLB-Misses zur Folge hat. Fuer einen Magento-Datenbankserver mit grossem Buffer Pool kann diese Reduktion messbar niedrigere Latenz bei Query-Ausfuehrung bedeuten, insbesondere bei Workloads mit vielen zufaelligen Speicherzugriffen ueber den gesamten Buffer Pool hinweg.

Der wichtigste Punkt, den viele Administratoren uebersehen: Es gibt zwei vollstaendig unterschiedliche Huge-Pages-Implementierungen unter Linux, und nur eine davon eignet sich fuer MySQL. Dieser Artikel zeigt, wie Huge Pages korrekt fuer den InnoDB Buffer Pool eingerichtet werden, und warum die automatische Alternative des Kernels genau das Gegenteil des gewuenschten Effekts bewirken kann.

2. Transparent Huge Pages: das haeufige Missverstaendnis

Transparent Huge Pages (THP) sind eine Kernel-Funktion, die automatisch und transparent fuer jede Anwendung grosse Speicherseiten zusammenfasst, ohne dass die Anwendung selbst etwas davon weiss. Das klingt zunaechst nach genau dem, was fuer MySQL gewuenscht ist, in der Praxis fuehrt THP bei Datenbank-Workloads aber regelmaessig zu Problemen. Der Grund liegt in der sogenannten khugepaged-Kernel-Thread, der im Hintergrund staendig versucht, kleine Seiten zu grossen Seiten zusammenzufassen (Compaction) und dabei kurzzeitig Speicherbereiche sperrt.

Fuer MySQL mit einem grossen, staendig aktiven Buffer Pool bedeutet diese Compaction-Aktivitaet sporadische, aber deutlich spuerbare Latenzspitzen, die in Monitoring-Tools als kurze, unregelmaessige Verzoegerungen auftauchen, ohne dass eine erkennbare Ursache im Datenbank-Log sichtbar wird. Diese Huge Pages-bezogenen Latenzspitzen sind so verbreitet, dass die offizielle MySQL-Dokumentation explizit empfiehlt, THP auf Datenbankservern zu deaktivieren, waehrend klassische Huge Pages ueber hugetlbfs stattdessen aktiv genutzt werden sollen.

3. Transparent Huge Pages dauerhaft deaktivieren

Der Status von THP wird ueber die virtuellen Dateien unter /sys/kernel/mm/transparent_hugepage/ gesteuert. Der Wert never fuer enabled deaktiviert THP fuer neue Speicherzuweisungen vollstaendig, waehrend defrag auf never zusaetzlich verhindert, dass der Kernel im laufenden Betrieb versucht, bestehende Speicherbereiche zu defragmentieren und in Huge Pages umzuwandeln.

Eine Aenderung ueber echo wirkt nur bis zum naechsten Neustart, deshalb braucht eine produktive Konfiguration einen systemd-Service, der diese Einstellung bei jedem Boot automatisch erneut setzt, bevor MySQL selbst startet. Ohne diese Automatisierung faellt der Server nach jedem Kernel-Update oder Neustart wieder auf die THP-Standardeinstellung zurueck, oft unbemerkt, bis die naechste Latenzspitze auftritt.

# Check current THP status (active value is in square brackets)
cat /sys/kernel/mm/transparent_hugepage/enabled
# [always] madvise never

# Disable THP immediately (temporary, lost on reboot without a service)
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# /etc/systemd/system/disable-thp.service
[Unit]
Description=Disable Transparent Huge Pages before MySQL starts
Before=mysql.service
DefaultDependencies=no

[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'
RemainAfterExit=yes

[Install]
WantedBy=basic.target

# Enable with: systemctl daemon-reload && systemctl enable --now disable-thp.service

4. hugetlbfs und vm.nr_hugepages konfigurieren

Waehrend THP transparent und automatisch arbeitet, muessen klassische Huge Pages ueber hugetlbfs explizit reserviert werden, bevor eine Anwendung sie nutzen kann. Der Sysctl-Parameter vm.nr_hugepages legt fest, wie viele 2-Megabyte-Seiten der Kernel dauerhaft aus dem allgemeinen Speicherpool herausloest und fuer die exklusive Nutzung durch Huge-Pages-faehige Anwendungen reserviert. Diese Reservierung reduziert automatisch den fuer andere Prozesse verfuegbaren regulaeren Arbeitsspeicher entsprechend, was bei der Server-Dimensionierung beruecksichtigt werden muss.

Ein kritischer Fallstrick: Die Reservierung funktioniert zuverlaessig nur direkt nach einem Neustart, wenn der Arbeitsspeicher noch wenig fragmentiert ist. Wird vm.nr_hugepages im laufenden Betrieb eines bereits lange laufenden Servers erhoeht, kann der Kernel moeglicherweise nicht genuegend zusammenhaengende physische 2-Megabyte-Bloecke finden, und die Reservierung schlaegt teilweise fehl, ohne eine deutliche Fehlermeldung zu liefern.

# /etc/sysctl.d/60-hugepages.conf
# Reserve 16400 x 2MB = ~32GB for the InnoDB buffer pool
vm.nr_hugepages = 16400

# Apply immediately (best right after boot, before memory fragments):
# sysctl -p /etc/sysctl.d/60-hugepages.conf

# Verify the actual reservation succeeded
grep -i huge /proc/meminfo
# HugePages_Total:   16400
# HugePages_Free:    16400
# Hugepagesize:       2048 kB

5. MySQL fuer large_pages einrichten

Damit MySQL die reservierten Huge Pages tatsaechlich nutzt, muss zusaetzlich die MySQL-Konfigurationsoption large_pages = 1 gesetzt werden. Ohne diese Option ignoriert MySQL die verfuegbaren Huge Pages vollstaendig und allokiert den Buffer Pool weiterhin mit regulaeren 4-Kilobyte-Seiten, selbst wenn vm.nr_hugepages korrekt konfiguriert ist. Zusaetzlich muss der MySQL-Betriebssystembenutzer Mitglied der Gruppe sein, der ueber vm.hugetlb_shm_group Zugriff auf die reservierten Seiten gewaehrt wird.

Nach dem Neustart von MySQL mit aktivierter large_pages-Option zeigt das MySQL-Error-Log explizit an, ob die Huge Pages erfolgreich genutzt werden konnten. Eine Fehlermeldung zu diesem Zeitpunkt deutet meist darauf hin, dass entweder nicht genuegend Huge Pages reserviert wurden, oder dass die Berechtigungen zwischen dem hugetlbfs-Mount und dem MySQL-Prozess nicht korrekt zusammenpassen.

# /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
large_pages = 1
innodb_buffer_pool_size = 32G
innodb_buffer_pool_instances = 8

# Allow the mysql OS user to access reserved huge pages
# /etc/sysctl.d/60-hugepages.conf (append)
echo 'vm.hugetlb_shm_group = 121' | sudo tee -a /etc/sysctl.d/60-hugepages.conf
# 121 = gid of the 'mysql' group, verify with: getent group mysql

sysctl -p /etc/sysctl.d/60-hugepages.conf
systemctl restart mysql

# Confirm success in the error log
grep -i "large page" /var/log/mysql/error.log

6. Die richtige Anzahl Huge Pages berechnen

Die Anzahl der zu reservierenden Huge Pages muss mindestens dem konfigurierten innodb_buffer_pool_size entsprechen, plus einem zusaetzlichen Puffer fuer andere MySQL-interne Speicherstrukturen, die ebenfalls Huge Pages nutzen koennen. Eine zu knappe Berechnung fuehrt dazu, dass MySQL beim Start nur einen Teil des Buffer Pools mit Huge Pages allokieren kann, was in der Praxis oft schlechter ist als gar keine Huge Pages zu nutzen, weil dann ein Teil des Speichers ueber den langsameren Standard-Pfad verwaltet wird.

Die Formel lautet: innodb_buffer_pool_size in Megabyte, geteilt durch 2 (Megabyte pro Huge Page), zuzueglich etwa 5 Prozent Sicherheitspuffer fuer interne MySQL-Strukturen wie den Adaptive Hash Index und Log-Puffer. Fuer einen 32-Gigabyte-Buffer-Pool ergibt das rechnerisch 32768 MB / 2 MB, also 16384 Huge Pages, aufgerundet mit Sicherheitspuffer auf die zuvor gezeigten 16400.

7. Aktivierung validieren und Fehler erkennen

Nach dem Neustart von MySQL zeigt /proc/meminfo unter HugePages_Free, wie viele der reservierten Huge Pages tatsaechlich noch ungenutzt sind. Sinkt dieser Wert nach dem MySQL-Start deutlich, deckt sich das mit der erwarteten Nutzung durch den Buffer Pool. Bleibt HugePages_Free hingegen nahezu unveraendert bei fast dem Gesamtwert, hat MySQL die Huge Pages trotz Konfiguration nicht genutzt, meist wegen fehlender Berechtigungen oder einer falsch gesetzten vm.hugetlb_shm_group.

Das MySQL-Error-Log ist die zuverlaessigste Quelle, um die tatsaechliche Nutzung von Huge Pages zu bestaetigen. Eine explizite Meldung ueber erfolgreiche Nutzung oder ein Fallback auf reguraere Seiten wird beim Start protokolliert, ein regelmaessiger Blick in dieses Log nach jedem MySQL-Neustart oder Server-Reboot ist deshalb Teil einer soliden Betriebspraxis.

8. Typische Fehler beim Huge-Pages-Setup

Der haeufigste Fehler ist, THP nicht zu deaktivieren, in der Annahme, dass klassische Huge Pages und Transparent Huge Pages sich gegenseitig ausschliessen oder THP automatisch weichen wuerde, sobald hugetlbfs konfiguriert ist. Beide Mechanismen arbeiten unabhaengig voneinander, und aktives THP kann parallel zu konfigurierten klassischen Huge Pages weiterhin Latenzspitzen fuer alle anderen Prozesse auf dem Server verursachen, auch wenn MySQL selbst korrekt klassische Huge Pages nutzt.

Ein zweiter haeufiger Fehler ist, vm.nr_hugepages im laufenden Betrieb eines Servers mit stark fragmentiertem Speicher zu setzen, statt die Reservierung direkt nach einem Neustart vorzunehmen. Die Reservierung schlaegt dann teilweise fehl, ohne dass der Administrator sofort eine klare Fehlermeldung erhaelt, und der Buffer Pool startet mit weniger Huge Pages als eigentlich vorgesehen, was den erwarteten Performance-Gewinn ganz oder teilweise zunichtemacht.

9. THP vs. klassische Huge Pages im Vergleich

Die folgende Tabelle stellt die beiden Huge Pages-Mechanismen unter Linux gegenueber und zeigt, warum fuer MySQL eine klare Empfehlung gilt.

Fuer produktive MySQL-Server mit grossem InnoDB Buffer Pool ist die klare Empfehlung: Transparent Huge Pages deaktivieren, klassische Huge Pages ueber hugetlbfs reservieren, und MySQL mit large_pages = 1 explizit auf diese Reservierung verweisen. Diese Kombination liefert den TLB-Vorteil ohne die Latenzrisiken der automatischen Compaction.

10. Zusammenfassung

Huge Pages reduzieren TLB-Misses fuer grosse InnoDB Buffer Pools erheblich, indem sie die Anzahl der zu verwaltenden Page-Table-Eintraege drastisch senken. Der entscheidende Unterschied liegt zwischen der automatischen, aber latenzanfaelligen Transparent-Huge-Pages-Funktion und den expliziten, ueber hugetlbfs reservierten klassischen Huge Pages. Fuer MySQL gilt die klare Empfehlung: THP deaktivieren, hugetlbfs mit ausreichend Reserve konfigurieren, und MySQL ueber large_pages = 1 explizit anweisen, diese Reservierung zu nutzen.

Die Reservierung sollte direkt nach einem Neustart erfolgen, solange der Speicher noch wenig fragmentiert ist, und ein systemd-Service sollte THP bei jedem Boot zuverlaessig deaktivieren, bevor MySQL startet. Wer diese Huge Pages-Konfiguration korrekt einrichtet und ueber /proc/meminfo sowie das MySQL-Error-Log validiert, gewinnt messbare TLB-Effizienz ohne das Risiko sporadischer Latenzspitzen.

11. FAQ: Huge Pages fuer MySQL unter Linux einsetzen