Für Administratoren Für IT-Manager
Forum Magazin Kontakt
IT Knowledge Network it-admin.tech Technik, Betrieb und Problemlösung

IT-Admin.tech

Kernel-Tuning für Datenbanken: THP, vm.swappiness und I/O‑Scheduler praxisnah

Architekturdiagramm eines Datenbankhosts mit Page-Cache, THP, Swap und Block-I/O-Queue vor einer NVMe-SSD
Technisches Diagramm: Transparent Hugepages, Page Cache, Swap und Block-I/O-Queue eines Datenbankhosts — NVMe-SSD als klares Artefakt für Storage-Entscheidungen.

Für stabile Produktionsdatenbanken ist gezieltes Kernel-Tuning für Datenbanken oft effektiver als reines Hochskalieren. Drei Kernel-Stellschrauben beeinflussen Performance und Latenz besonders stark: Transparent Hugepages (THP), vm.swappiness und der I/O‑Scheduler. Dieser Praxisleitfaden erklärt, wie diese Mechanismen arbeiten, welche Auswirkungen sie auf Betrieb, Monitoring und Sicherheit haben, wie Sie Änderungen messen, sicher ausrollen und wieder zurücknehmen — einschließlich spezieller Hinweise für Container (Docker/Podman) und Virtualisierung.

Kernel-Tuning für Datenbanken: Vor dem Tunen: Ziele, Metriken und Change-Plan

Bevor Sie an Kernel‑Parametern drehen, definieren Sie messbare Ziele (z. B. p95/p99-Reduktion, stabilere fsync‑Zeiten) und akzeptable Risiken. Legen Sie KPIs fest, die Sie automatisch sammeln können: Query-Latenzen aus der Datenbank, hostseitige iostat/iowait, vmstat (si/so = Swap-In/Swap-Out), PSI (Pressure Stall Information — ein Kernel-Mechanismus zur Messung von CPU/Memory/IO-Pressure), sowie Kernel-Logs (dmesg/journal). Ohne klare Metrik sind Rückschlüsse schwer.

Kurze Baseline-Checks

Shell
# Systemübersicht
uname -r; cat /etc/os-release; systemd-detect-virt || true

# Speicher, Swap und PSI
free -h; swapon --show; vmstat 1 5; sudo cat /proc/pressure/memory

# I/O
lsblk -o NAME,TYPE,SIZE,ROTA,MOUNTPOINTS
iostat -xz 1 5 || true

# THP-Status
for f in /sys/kernel/mm/transparent_hugepage/enabled /sys/kernel/mm/transparent_hugepage/defrag; do
  [ -f "$f" ] && echo "$f: $(cat $f)"
done

Dokumentieren Sie Versionsinformationen (Kernel, Distribution, Storage-Treiber), weil Verhalten zwischen Kernel-Versionen variieren kann.

Transparent Hugepages (THP): Mechanik, Risiken und Praxis

THP versucht, durch Zusammenfassen vieler kleiner Seiten zu großen (typisch 2 MiB) Seiten TLB‑Misses (TLB = Translation Lookaside Buffer, ein Cache für virtuelle→physische Adressen) zu reduzieren. Das hilft numerisch-intensiven Workloads, kann bei transaktionalen Datenbanken aber unerwartete Pausen erzeugen: Kernel‑Defragmentierung und Kopy‑Operations beim Zusammenfügen großer Seiten verursachen kurzzeitige CPU- oder Memory‑Stalls, die p99‑Latenzen deutlich erhöhen.

Wann THP wahrscheinlich Probleme macht

  • Plötzliche p99-Spitzen ohne erkennbaren I/O-Trigger.
  • Kernel-Defrag- oder kswapd‑Aktivität bei hoher Memory-Utilisation.
  • Reproduzierbare Latenzspitzen bei bestimmten Abfrageprofilen.

Testen, Deaktivieren und Persistenz

Änderungen lassen sich zur Laufzeit über sysfs testen; für Produktion sollten persistente, zurückrollbare Mechanismen genutzt werden (systemd‑Unit, GRUB-Commandline oder Initramfs-Anpassung).

Shell
# Laufzeit-Test: THP deaktivieren
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

# Kontrolle
cat /sys/kernel/mm/transparent_hugepage/enabled
cat /sys/kernel/mm/transparent_hugepage/defrag

Beispiel für eine kurze, sichere systemd‑Unit, die THP beim Boot deaktiviert. Unit-Inhalt als Datei anlegen:

Shell
sudo tee /etc/systemd/system/disable-thp.service >/dev/null <<'EOF'
[Unit]
Description=Disable Transparent Huge Pages
After=network.target

[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=multi-user.target
EOF

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

Alternativ können Sie in GRUB den Kernel-Parameter transparent_hugepage=never setzen (siehe nächster Abschnitt). Wichtig: Testen Sie über mehrere Lastprofile und messen Sie p95/p99 vor/nach der Änderung.

vm.swappiness: Verständnis, Tuning und Risiken

vm.swappiness ist ein Kernel-Parameter (0–100) und beschreibt, wie aggressiv der Kernel anonymen Speicher in Swap auslagert. Ein niedriger Wert reduziert Swapping im Normalbetrieb — oft sinnvoll für Datenbank-Hosts, weil Swap-Latenzen Queries stark ausbremsen. Dennoch ist nicht automatisch vm.swappiness=0 die beste Wahl: In Systemen mit begrenztem RAM oder gemischten Workloads kann aggressive Vermeidung von Swap zu stärkerem Page Reclaim führen, was CPU- und I/O-Last erhöht.

Setzen und persistent machen

Shell
# Aktuellen Wert prüfen
sysctl vm.swappiness; cat /proc/sys/vm/swappiness

# Laufzeit setzen
sudo sysctl -w vm.swappiness=10

# Dauerhaft (sysctl.d)
sudo tee /etc/sysctl.d/99-db-tuning.conf >/dev/null <<'EOF'
# DB-Tuning: Swap-Verhalten
vm.swappiness = 10
EOF
sudo sysctl --system

Besonderheiten bei Containern und cgroups

In Container-Umgebungen ist unpassendes Swapping häufig ein Folgeproblem: Ein Container kann am cgroup-Limit sein, obwohl der Host freien RAM zeigt. Bei cgroup v1/v2 unterscheiden sich Parameter und Verhalten; relevante Einstellungen sind unter anderem memory.swap.max und memory.high (cgroup v2). Orchestratoren (Kubernetes, Docker Engine) setzen manchmal Defaults, die das Container-Verhalten beeinflussen.

Shell
# Docker: Memory-Limits prüfen und Container-Startbeispiel
docker inspect --format '{{.Name}}: Memory={{.HostConfig.Memory}} MemorySwap={{.HostConfig.MemorySwap}}' postgres

# Starten ohne zusätzliches Swap (Host verhindert swap usage durch MemorySwap)
docker run -d --name postgres 
  --memory=8g --memory-swap=8g 
  -v /srv/dbdata:/var/lib/postgresql/data 
  my-postgres-image

Empfehlung: Setzen Sie Container- und Host-Limits konsistent, testen Sie OOM-Verhalten (Kernel OOM oder systemd-oomd) und überwachen dmesg/journal auf OOM- oder OOM-Killer‑Ereignisse.

I/O‑Scheduler: Auswahl nach Storage-Typ und Schleifenfallen

Der I/O‑Scheduler beeinflusst Ordnung, Priorisierung und Queueing von Block-I/O. Moderne Linux-Kernel verwenden Multi-Queue (blk-mq). Typische Regeln:

  • Lokale NVMe: none (Device-side scheduler ist oft besser als Linux queuing).
  • Virtuelle Disks (VirtIO, VMware): mq-deadline reduziert Latenz-Ausreißer.
  • HDDs oder interaktive Desktop-Workloads: bfq kann fairness- und latenzsensitiv sein.

Wichtig: Bei Schichten wie LVM, Device-Mapper (dm‑crypt) oder Multipath müssen Sie den Scheduler an der richtigen Ebene setzen — oft auf dem physischen Device, nicht auf dem LVM-Device.

Prüfen, setzen und persistieren

Shell
# Aktuelle Scheduler
for d in /sys/block/*/queue/scheduler; do
  echo "${d%/queue/scheduler}: $(cat $d)"
done

# Laufzeit-Änderung (Beispiel für nvme0n1)
echo none | sudo tee /sys/block/nvme0n1/queue/scheduler

# Persistenz mit udev-Regel
sudo tee /etc/udev/rules.d/60-io-scheduler.rules >/dev/null <<'EOF'
ACTION=="add|change", KERNEL=="nvme*", ATTR{queue/scheduler}="none"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="mq-deadline"
EOF
sudo udevadm control --reload-rules; sudo udevadm trigger --type=devices --action=change

Beachten Sie Cloud-Instanzen (z. B. AWS EBS gp3, Azure Managed Disks): das darunterliegende Verhalten kann virtualisiert sein; testen Sie mit realer Arbeitslast. Bei Multipath gilt: setzen Sie Scheduler auf den Backend-Devices, nicht nur auf /dev/mapper/…

Messverfahren: verlässliche Tests und Tools

Kernel-Tuning macht nur dann Sinn, wenn Sie die Wirkung sauber messen. Verwenden Sie kombinierte Host- und DB-Tests:

  • DB-Workload-Tools: pgbench für PostgreSQL, sysbench für MySQL, native Benchmark-Suites. Diese erzeugen realistischere Zugriffsmuster als synthetische I/O-Tools allein.
  • Host‑Tools: iostat (await, %util), blktrace für tiefe Block-I/O-Analyse, fio für kontrollierte I/O-Profile.
  • Kernel-Observability: /proc/pressure/* für PSI, eBPF-Profiling (bcc, bpftrace) um Stalls und Schlangen sichtbar zu machen.
Shell
# Beispiel: fio für fsync-stress (synchrones write + fsync)
fio --name=fsync-test --filename=/srv/dbdata/testfile --size=4G 
  --bs=4k --iodepth=1 --numjobs=1 --rw=write --direct=1 --fsync=1 --runtime=300

# Simplifiziertes pgbench-Laufbeispiel
docker exec -it postgres pgbench -c 50 -T 120 -r mydb

Wichtig: Führen Sie Tests in einem repräsentativen Zeitfenster aus (nicht nur kurz), um p99‑Verhalten einzufangen.

Troubleshooting: Warum Tuning keine Wirkung zeigt

Wenn Änderungen keine Verbesserung bringen, prüfen Sie:

  • Liegt die Datenbankdatei wirklich auf dem getunten Device? (bind‑mounts, LVM, dm‑crypt, Multipath).
  • Stammt Latenz aus dem Storage-Array oder Netzwerk (NAS/SAN/Cloud)?
  • Wird Rechenzeit in der DB selbst verbraucht (Locking, Checkpoints) statt im Host-IO-Pfad?
  • Sind Container‑cgroups, systemd-oomd oder Orchestrator-Policies die Ursache?

Oft ist Kernel-Tuning nur ein Teil eines größeren Maßnahmenpakets: Storage-Optimierung, Tune der DB‑Werte (Checkpoint-Intervalle, background writer) und I/O‑Pfad-Analyse sind zusammen zu betrachten.

Rollback-Strategie und Beispiel-Skript

Bereiten Sie immer automatisierbare Rollbacks vor. Sichern Sie aktuelle Werte vor Änderung und stellen Sie eine einfache Wiederherstellung bereit.

Shell
#!/bin/bash
# rollback-tuning.sh - einfache Rücksetz-Routine
set -euo pipefail

echo "Sichern aktueller Werte..."
mkdir -p /root/kernel-tuning-backup
cat /sys/kernel/mm/transparent_hugepage/enabled > /root/kernel-tuning-backup/thp_enabled
cat /sys/kernel/mm/transparent_hugepage/defrag > /root/kernel-tuning-backup/thp_defrag
cat /proc/sys/vm/swappiness > /root/kernel-tuning-backup/swappiness
for d in /sys/block/*/queue/scheduler; do
  dev=${d%/queue/scheduler}
  cat $d > "/root/kernel-tuning-backup/$(basename $dev)_scheduler"
done

# Rollback-Schritte (Beispielwerte aus Backup zurücklesen)
echo "Rollback: THP zurücksetzen"
[ -f /root/kernel-tuning-backup/thp_enabled ] && cat /root/kernel-tuning-backup/thp_enabled | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
[ -f /root/kernel-tuning-backup/thp_defrag ] && cat /root/kernel-tuning-backup/thp_defrag | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

echo "Rollback: swappiness zurücksetzen"
[ -f /root/kernel-tuning-backup/swappiness ] && sudo sysctl -w vm.swappiness=$(cat /root/kernel-tuning-backup/swappiness)

# Hinweis: Scheduler-Rollback kann ein Reboot erfordern, je nach udev/driver

echo "Rollback abgeschlossen - prüfen Sie Logs und KPIs"

Dokumentieren Sie die ursprünglichen Werte in Ihrem Ticketing-System und führen Sie nach dem Rollback einen Validierungs-Check der KPIs durch.

Besonderer Fokus: Docker und cgroup v2

In Container-Szenarien gilt: Die meisten Kernel-Einstellungen werden auf Host-Ebene wirksam; Container-Rechte und cgroup-Konfigurationen können aber Verhalten ändern. Bei cgroup v2 lauten relevante Einstellungen unter /sys/fs/cgroup: memory.high (weiche Begrenzung), memory.swap.max (Swap-Limit) und memory.max (harte Begrenzung). Kubernetes verwendet QoS-Klassen (Guaranteed/Burstable/BestEffort) — setzen Sie Requests und Limits sauber, damit Container erwartbar arbeiten.

Shell
# Beispiel: Werte in cgroup v2 prüfen (Pfad kann je nach Engine variieren)
cat /sys/fs/cgroup//memory.high
cat /sys/fs/cgroup//memory.swap.max

# Kubernetes: PodSpec (Ausschnitt)
# requests/limits sicher definieren, um unerwarteten Swap zu vermeiden

Erstellen Sie Testfälle für OOM-Szenarien und prüfen Sie, wie Ihre Orchestrator‑Policies (Eviction thresholds, PodDisruptionBudget) darauf reagieren.

Praktische Betriebsregeln und Empfehlungen

  • Ändern Sie nur eine Kernel-Variable pro Testfenster, damit Effekte eindeutig zuordenbar sind.
  • Automatisieren Sie Backups der vorherigen Werte und Rollback-Skripte.
  • Bei Cloud- oder SAN-Storage zuerst prüfen, ob die Latenzquelle außerhalb des Hosts liegt.
  • Nutzen Sie eBPF-Tools, um kurze Kernel‑Stalls sichtbar zu machen, die Monitoring-Tools oft übersehen.
  • Halten Sie Persistenzregeln (sysctl.d, udev, systemd) versioniert im Configuration-Repository.

Fazit

Kernel-Tuning für Datenbanken ist eine wirkungsvolle, aber präzise Aufgabe: Transparente Hugepages sind häufiger Ursache für p99‑Spitzen, vm.swappiness muss zu RAM‑Planung und cgroup‑Policy passen, und der I/O‑Scheduler sollte entsprechend dem Storage‑Typ gewählt werden. Arbeiten Sie methodisch: Baseline, gezielte Änderung, Messung, Persistenztest (Reboot) und klarer Rollback‑Plan. Nur so erzielen Sie reproduzierbare Verbesserungen in Bare‑Metal, VMs und Container-Umgebungen.

Dieses Runbook ist als operatives Nachschlagewerk gedacht: Passen Sie Werte an Ihre Infrastruktur an, testen Sie mit realen Workloads und hinterlegen Sie alle Schritte revisionssicher in Ihrem Change‑Management.

Betrieb, Upgrade- und Integrationsaspekte

Zusätzlich zur punktuellen Parameteranpassung lohnt es sich, Kernel-Tuning in ein betriebliches Zusammenspiel einzubetten: Kernel‑ und Treiber‑Upgrades, NVMe‑/Firmware‑Level, NUMA‑Topologie und Datenbank‑Konfigurationen interagieren stark und können Veränderungen maskieren oder verstärken. Bevor Sie breit ausrollen, prüfen Sie Kompatibilität mit Storage‑Treibern (nvme, virtio, multipath) und Firmware‑Releases; manche Latenzänderungen sind treiber‑ oder firmwarebedingt und nicht durch sysctl behebbar.

Architekturhinweise

  • NUMA: Platzieren Sie DB‑Threads, Page‑Cache und Datenfiles vorzugsweise auf der gleichen NUMA‑Domain; falsche Affinität erhöht Cross‑node‑Traffic.
  • DB‑Konfiguration: Stimmen Sie shared_buffers/innodb_buffer_pool so ab, dass Host‑Page‑Cache und DB‑Cache nicht in Konflikt stehen; das reduziert unnötige Reclaims.
  • Cloud/Managed DB: Bei Managed Services sind Kernel‑Einstellungen oft nicht verfügbar — wählen Sie stattdessen passende Instance‑Klassen, Provisioned IOPS oder spezialisierte Storage‑Optionen.

Betriebs- und CI‑Integration

Automatisieren Sie Tests in Ihrer Pipeline: Führen Sie fio/pgbench-Läufe als Teil von Release‑Pipelines auf einer kleineren Canary‑Flotte aus und integrieren Sie Ergebnisvergleich (p50/p95/p99) ins CI‑Reporting. Versionieren Sie sysctl.d, udev‑Rules und systemd‑Units im Configuration‑Repository und deployen Sie idempotent per Ansible/Chef.

Monitoring‑Checkliste

  • Alert für PSI‑Memory > definierter Schwelle (z. B. 100ms) und für anhaltende Swap‑Outs.
  • Trendüberwachung: p99‑Latenzen, iowait, await und kernel OOM‑Events.
  • Audit: Kernel‑Parameter und Udev‑Regeln per Configuration‑Drift‑Scan prüfen.

Diese betrieblichen Perspektiven stellen sicher, dass Kernel‑Tuning Teil eines verlässlichen Change‑Managements für Ihre individuellen Unternehmenssoftware‑Landschaft bleibt und nicht zu unerwarteten Seiteneffekten führt.

Für dieses Thema sind auch Transparent Hugepages Deaktivieren und I/O-Scheduler Mq-Deadline Bfq None wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.

Cgroups Speicherlimits Docker I/O-Scheduler Mq-Deadline Bfq None Kernel-Tuning Für Datenbanken Kernel-Tuning Für Datenbanken: Transparent Hugepages, Swappiness Und I/O-Scheduler Swap Verhalten Datenbankserver Thp Datenbank Latenz Transparent Hugepages Deaktivieren Vm.swappiness

Weiterfuehrend

Passende weitere Inhalte