MySQL 8 InnoDB Buffer Pool Tuning auf Netcup & Hetzner VPS Instanzen

Netcup vServer (VPS) und Hetzner Cloud-Server erfreuen sich im deutschsprachigen Raum enormer Beliebtheit bei Webentwicklern und Agenturen. Doch bei der Bereitstellung von MySQL 8 auf Systemen mit 4 GB bis 8 GB RAM erleben viele Entwickler ein böses Erwachen: Nach einigen Tagen oder während nächtlicher Backups beendet der Linux-Kernel den Datenbankprozess abrupt (mysqld: Killed process / Exit Code 137).

Ursache ist der berüchtigte Linux Out-Of-Memory (OOM) Killer, ausgelöst durch fehlerhaft dimensionierte Puffergrößen im InnoDB-Speichermodul.

Hier ist die praxiserprobte Dimensionierungsformel und Konfiguration für unmanaged Cloud-Instanzen in Deutschland.

1. Forensische Diagnose: Hat der OOM-Killer zugeschlagen?

Überprüfen Sie nach einem plötzlichen Datenbankausfall das Systemprotokoll mit dmesg:

# OOM-Killer Spuren im Kernel-Log suchen
sudo dmesg -T | grep -i -E "(oom-killer|killed process.*mysqld)"

# Typische Ausgabe bei Speicherüberlauf:
# [Mon Mar 02 03:15:22 2026] Out of memory: Killed process 1420 (mysqld) total-vm:4210452kB, anon-rss:2984112kB

Wenn MySQL durch OOM getötet wird, liegt das fast nie an einem Softwarefehler, sondern daran, dass die Summe aus innodb_buffer_pool_size, dynamischen Thread-Puffern (join_buffer_size, sort_buffer_size) und den Anforderungen des Webservers (PHP-FPM, Nginx) den physischen Arbeitsspeicher überstiegen hat.

2. Die präzise Dimensionierungsformel für 4GB & 8GB VPS

Verlassen Sie sich nicht auf die veraltete Daumenregel “Setze den Buffer Pool auf 80% des RAMs”. Das gilt nur für dedizierte Datenbankserver mit 64GB+ RAM. Auf einem 4GB All-in-One VPS (Nginx + PHP-FPM + MySQL) führt das zum sofortigen Absturz!

Formel für Kombi-Server (Webserver + DB auf derselben Instanz):

$$\text{Puffergröße} = (\text{Gesamt-RAM} - \text{OS-Reserve (800MB)} - (\text{max_children} \times 60\text{MB})) \times 0.85$$

Für eine 4 GB RAM Netcup Instanz:

• Betriebssystem + Nginx Reserve: 800 MB
• PHP-FPM (15 Prozesse à 60 MB): 900 MB
• MySQL Thread Buffer Reserve: 400 MB
• Verfügbar für innodb_buffer_pool_size: 1.536 MB (1,5 GB)

Für eine 8 GB RAM Hetzner Instanz:

• Verfügbar für innodb_buffer_pool_size: 4.096 MB (4,0 GB)

3. Optimierte MySQL 8 Konfiguration in /etc/mysql/conf.d/tuning.cnf

Legen Sie eine saubere Konfigurationsdatei an:

# /etc/mysql/conf.d/tuning.cnf

[mysqld]
# 1. InnoDB Hauptpuffer (Beispiel für 4GB Server)
innodb_buffer_pool_size = 1536M
innodb_buffer_pool_instances = 2 # Ab 1GB Buffer Pool auf 2 Instanzen aufteilen

# 2. Redo-Log & Flushing (SSD/NVMe optimiert für Netcup/Hetzner)
innodb_redo_log_capacity = 512M
innodb_flush_log_at_trx_commit = 2 # 1 Sekunde Pufferung für 10x schnellere Schreibvorgänge
innodb_flush_method = O_DIRECT

# 3. I/O Capacity für NVMe Cloud-Speicher
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000

# 4. Begrenzung dynamischer Verbindungen & Threads (Verhindert RAM-Spitzen)
max_connections = 60
join_buffer_size = 256K
sort_buffer_size = 512K
read_rnd_buffer_size = 256K

# 5. Tabellen- & Dateideskriptoren
table_open_cache = 4000
open_files_limit = 65535

4. Linux Kernel Swappiness Tuning

Verhindern Sie, dass der Linux-Kernel InnoDB-Speicherbereiche auf die Auslagerungsdatei (Swap) auslagert, was zu massiven I/O-Lags führen würde:

# Swappiness auf konservative 10 setzen
echo "vm.swappiness = 10" | sudo tee -a /etc/sysctl.d/99-mysql-swappiness.conf
sudo sysctl -p /etc/sysctl.d/99-mysql-swappiness.conf

Starten Sie MySQL neu und überprüfen Sie den Status:

sudo systemctl restart mysql
mysql -u root -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool%';"

5. Vorher-Nachher Metriken im Dauerbetrieb

Stabile Betriebszeiten, null ungeplante Server-Neustarts und ein robuster Origin-Stack für Ihre geschäftskritischen Webprojekte.

🔗 Zusammenhängende Systemdiagnosen & Infrastruktur-Geflecht:

Server- und Performance-Engpässe treten selten isoliert auf. Origin-Server-Latenzen, Datenbankstrukturen und Frontend-Metriken greifen direkt ineinander:

• Redis Object Cache & Session-Locking in Shopware 6 beheben: Warenkorb-Lags und Session-Timeouts bei Lastspitzen eliminieren.
• Brotli statische Vorkomprimierung auf Nginx-Webservern: CPU-Last bei der Auslieferung textbasierter Assets um bis zu 40% senken.
• Shopware 6 Performance Triage & Latenz-Beseitigung: Datenbank-Overhead und Cache-Invalidierung im deutschen E-Commerce lösen.