InnoDB Buffer Pool nach Messdaten dimensionieren

Cookbook: Ziel und Ergebnis

Der Buffer Pool erhält genug RAM für häufig genutzte InnoDB-Seiten, ohne PHP, Betriebssystem und andere Dienste in Swap oder OOM zu drängen.

Rezept: Schritt für Schritt

1. GesamtrAM, Spitzenverbrauch von OS, Webserver/PHP, Redis und sonstigen Diensten messen.
2. Größe aktiver InnoDB-Daten plus Indizes sowie Buffer-Pool-Nutzung über mehrere Lastzyklen erfassen.
3. Ein sicheres DB-Budget mit mindestens 10–20 % Systemreserve bilden; bei All-in-one-Servern PHP-Spitze ausdrücklich abziehen.
4. In kleinen Schritten ändern und Cache-Aufwärmphase abwarten. MariaDB/MySQL-Version und dynamische Änderbarkeit prüfen.

Rechenweg oder Entscheidungsregel

DB-RAM-Budget = RAM gesamt − OS-Reserve − PHP-Spitze − andere Dienste\nStartwert Buffer Pool = min(aktive InnoDB-Daten × 1,1 bis 1,3; DB-RAM-Budget × 0,7 bis 0,85)

Die oft zitierte 70–80-%-Regel passt eher zu einem dedizierten DB-Server, nicht automatisch zu einem WordPress-All-in-one-Host.

Praxisbeispiel

8-GB-All-in-one: OS 1,5 GB, PHP-Spitze 2,5 GB, Redis/sonstiges 0,5 GB, Reserve 0,8 GB → rund 2,7 GB DB-Budget; Start 2 GB. Dedizierter 32-GB-DB-Host mit 18 GB aktivem Datensatz kann mit 20–22 GB starten und die restliche RAM-Nutzung beobachten.

Prüfen, ob es funktioniert

• Buffer-Pool-Hit-Rate, Reads von Datenträger, Query-Latenz, RAM und Swap über Spitzenzeiten vergleichen.
• Keine OOM-Kills; mindestens dokumentierte Reserve bleibt frei/verfügbar.
• Neustartverhalten und Konfigurationspersistenz prüfen.

Rollback

Vorherigen innodb_buffer_pool_size-Wert wiederherstellen, Konfiguration validieren und nach Versionsvorgabe dynamisch setzen oder Wartungsneustart durchführen. Cache-Aufwärmphase einkalkulieren; nicht wegen kurzzeitig kalter Werte weiterdrehen.

Funktion

Der InnoDB Buffer Pool hält Tabellen- und Indexseiten im RAM. Wiederholte Zugriffe benötigen dadurch weniger Datenträger-I/O. WordPress profitiert besonders bei größeren, aktiven Datenbeständen und vielen ungecachten Anfragen.

Keine pauschalen 80 Prozent

MySQL nennt bis zu 80 % physischen Speichers als möglichen Ausgangspunkt auf einem dedizierten Datenbankserver und warnt zugleich vor zusätzlichem Speicherbedarf und Paging. Auf einem WordPress-All-in-one-Server teilen sich Datenbank, PHP-FPM, Webserver, Redis und Betriebssystem den RAM; dort muss der Anteil deutlich anders ausfallen.

Vorgehen

Erfasse Datensatzgröße, Arbeitssatz, Buffer-Pool-Nutzung, Reads vom Datenträger, Swap und Spitzenlast. Ändere in kleinen Schritten und halte Reserve für PHP-Prozesse. Große Pools verlängern Start und Warmup; aktuelle Server können den Zustand sichern und wieder laden.

Erfolgskontrolle

Gesucht sind weniger physische Reads und stabilere Query-Latenzen ohne Swap, OOM-Kills oder verdrängte PHP-Worker. Auf Managed Hosting ist dies eine Anfrage an den Betreiber, kein functions.php-Tipp.

Quellen und Prüfstand

• MySQL 8.4: Buffer-Pool-Variable
• MariaDB: InnoDB Buffer Pool

Inhalt fachlich geprüft am 17. August 2026. Konkrete Werte sind Ausgangspunkte, keine Universaldosierung.