Tuning del kernel per database: THP, vm.swappiness e I/O scheduler in pratica

Per database di produzione stabili, un mirato Kernel-Tuning für Datenbanken è spesso più efficace del semplice upscaling. Tre manopole del kernel influenzano in modo particolarmente marcato performance e latenza: Transparent Hugepages (THP), vm.swappiness e lo I/O‑Scheduler. Questa guida pratica spiega come funzionano questi meccanismi, quali effetti hanno su operazioni, monitoring e sicurezza, come misurare le modifiche, distribuirle in modo sicuro e ripristinarle — inclusi riferimenti specifici per container (Docker/Podman) e virtualizzazione.

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

Prima di intervenire sui parametri del kernel, definite obiettivi misurabili (es. riduzione p95/p99, tempi fsync più stabili) e rischi accettabili. Stabilite KPI che possano essere raccolte automaticamente: latenze delle query dal database, iostat/iowait sul host, vmstat (si/so = Swap-In/Swap-Out), PSI (Pressure Stall Information — un meccanismo del kernel per misurare CPU/Memory/IO-Pressure), oltre ai log del kernel (dmesg/journal). Senza metriche chiare le deduzioni sono difficili.

Kurze Baseline-Checks

# 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

Documentate le informazioni di versione (Kernel, distribuzione, driver di storage), perché il comportamento può variare tra versioni del kernel.

Transparent Hugepages (THP): Mechanik, Risiken und Praxis

THP cerca di ridurre i TLB‑Miss combinando molte piccole pagine in pagine grandi (tipicamente 2 MiB) per diminuire i miss del TLB (TLB = Translation Lookaside Buffer, una cache per indirizzi virtuali→fisici). Questo aiuta workload numerici intensivi, ma nei database transazionali può generare pause impreviste: la deframmentazione del kernel e le operazioni di copia durante l’unione di grandi pagine causano brevi stall di CPU o memoria che possono aumentare significativamente le latenze p99.

Wann THP wahrscheinlich Probleme macht

• Picchi improvvisi di p99 senza un trigger I/O riconoscibile.
• Attività di defrag del kernel o kswapd con alta utilizzazione della memoria.
• Picchi di latenza riproducibili con determinati profili di query.

Testen, Deaktivieren und Persistenz

Le modifiche possono essere testate a runtime tramite sysfs; in produzione è consigliabile usare meccanismi persistenti e reversibili (systemd‑Unit, riga di comando GRUB o adattamento dell’initramfs).

# 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

Esempio di una breve, sicura systemd‑Unit che disattiva THP al boot. Creare il contenuto della unità come file:

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

In alternativa, è possibile impostare in GRUB il parametro del kernel transparent_hugepage=never (vedi la sezione successiva). Importante: testare su più profili di carico e misurare p95/p99 prima/dopo la modifica.

vm.swappiness: Comprensione, Tuning e rischi

vm.swappiness è un parametro del kernel (0–100) e descrive quanto aggressivamente il kernel sposta in swap la memoria anonima. Un valore basso riduce lo swapping in condizioni normali — spesso sensato per host di database, perché la latenza dello swap rallenta fortemente le query. Tuttavia è non automaticamente vm.swappiness=0 la scelta migliore: in sistemi con RAM limitata o carichi misti, l’evitamento aggressivo dello swap può portare a un reclamare più intenso delle pagine, aumentando carico CPU e I/O.

Impostare e rendere persistente

# 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

Particolarità nei container e nelle cgroups

In ambienti containerizzati, uno swapping inappropriato è spesso un problema secondario: un container può raggiungere il limite della cgroup anche se l’host mostra RAM libera. Con cgroup v1/v2 i parametri e il comportamento differiscono; impostazioni rilevanti includono, tra le altre, memory.swap.max e memory.high (cgroup v2). Gli orchestratori (Kubernetes, Docker Engine) a volte impostano dei default che influenzano il comportamento dei container.

# 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

Raccomandazione: impostare limiti coerenti per container e host, testare il comportamento OOM (Kernel OOM o systemd-oomd) e monitorare dmesg/journal per eventi OOM o OOM-Killer.

I/O‑Scheduler: scelta in base al tipo di storage e trappole

Lo I/O‑scheduler influisce sull’ordinamento, la prioritizzazione e il queueing dell’I/O a blocchi. I kernel moderni Linux utilizzano Multi-Queue (blk-mq). Regole tipiche:

• NVMe locali: none (lo scheduler lato dispositivo è spesso preferibile al queueing Linux).
• Dischi virtuali (VirtIO, VMware): mq-deadline riduce i picchi di latenza.
• HDD o carichi interattivi desktop: bfq può essere sensibile a fairness e latenza.

Importante: per livelli come LVM, Device-Mapper (dm‑crypt) o Multipath bisogna impostare lo scheduler al livello corretto — spesso sul device fisico, non sul device LVM.

Verificare, impostare e rendere persistente

# 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

Tenere presente le istanze cloud (ad es. AWS EBS gp3, Azure Managed Disks): il comportamento sottostante può essere virtualizzato; testare con carico reale. In presenza di Multipath vale: impostare lo scheduler sui device backend, non solo su /dev/mapper/…

Procedure di misura: test e strumenti affidabili

L’ottimizzazione del kernel ha senso solo se si misurano correttamente gli effetti. Utilizzare test combinati lato host e DB:

• Strumenti per workload DB: pgbench per PostgreSQL, sysbench per MySQL, suite di benchmark native. Questi generano schemi di accesso più realistici rispetto ai soli strumenti I/O sintetici.
• Strumenti host: iostat (await, %util), blktrace per analisi approfondita del Block-I/O, fio per profili I/O controllati.
• Osservabilità del kernel: /proc/pressure/* per PSI, profilazione eBPF (bcc, bpftrace) per rendere visibili stall e code.

# 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

Importante: eseguire i test in un intervallo temporale rappresentativo (non solo breve) per catturare il comportamento p99.

Risoluzione dei problemi: perché il tuning non ha effetto

Se le modifiche non portano miglioramenti, verificare:

• Il file del database si trova effettivamente sul device ottimizzato? (bind‑mounts, LVM, dm‑crypt, Multipath).
• La latenza proviene dall’array di storage o dalla rete (NAS/SAN/Cloud)?
• Il tempo di CPU viene consumato all’interno del DB stesso (Locking, Checkpoints) invece che nel percorso I/O dell’host?
• Sono i cgroups dei container, systemd-oomd o le policy dell’orchestrator la causa?

Spesso il kernel-tuning è solo una parte di un pacchetto di interventi più ampio: l’ottimizzazione dello storage, il tuning dei parametri DB (intervalli di checkpoint, background writer) e l’analisi del percorso I/O vanno considerati congiuntamente.

Strategia di rollback e script di esempio

Predisporre sempre rollback automatizzabili. Salvare i valori correnti prima della modifica e fornire una procedura di ripristino semplice.

#!/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"

Documenti i valori originali nel vostro sistema di ticketing ed esegua dopo il rollback un controllo di validazione delle KPI.

Focus particolare: Docker e cgroup v2

Nei scenari con container vale: la maggior parte delle impostazioni del kernel si applica a livello dell’host; tuttavia i permessi dei container e le configurazioni delle cgroup possono modificare il comportamento. Con cgroup v2 le impostazioni rilevanti sotto /sys/fs/cgroup sono: memory.high (limitazione soft), memory.swap.max (limite di swap) e memory.max (limitazione hard). Kubernetes utilizza classi di QoS (Guaranteed/Burstable/BestEffort) — impostate chiaramente Requests e Limits affinché i container si comportino in modo prevedibile.

# 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

Crei casi di test per scenari OOM e verifichi come le policy del suo orchestrator (Eviction thresholds, PodDisruptionBudget) reagiscono.

Regole operative pratiche e raccomandazioni

• Modifichi una sola variabile del kernel per finestra di test, in modo che gli effetti siano chiaramente attribuibili.
• Automatizzi i backup dei valori precedenti e gli script di rollback.
• Per storage cloud o SAN verifichi prima se la sorgente di latenza è esterna all’host.
• Utilizzi strumenti eBPF per rendere visibili brevi stall del kernel che gli strumenti di monitoring spesso non rilevano.
• Mantenga le regole di persistenza (sysctl.d, udev, systemd) versionate nel repository di configurazione.

Conclusione

Ottimizzazione del kernel per i database è un’attività efficace ma precisa: le Transparent Hugepages sono spesso causa di picchi p99, vm.swappiness deve essere coerente con la pianificazione della RAM e con la cgroup‑Policy, e lo I/O‑Scheduler dovrebbe essere scelto in base al tipo di storage. Lavori in modo metodico: baseline, modifica mirata, misurazione, test di persistenza (reboot) e un chiaro piano di rollback. Solo così si ottengono miglioramenti riproducibili su bare‑metal, VM e ambienti containerizzati.

Questo runbook è pensato come guida operativa: adatti i valori alla sua infrastruttura, testi con carichi di lavoro reali e registri tutti i passaggi in modo revisionabile nel suo change‑management.

Operazioni, aspetti di upgrade e integrazione

Oltre all’adattamento puntuale dei parametri conviene inserire il kernel tuning in un contesto operativo: aggiornamenti del kernel e dei driver, livelli NVMe/firmware, topologia NUMA e configurazioni del database interagiscono fortemente e possono mascherare o amplificare le variazioni. Prima di effettuare un rollout esteso, verificate la compatibilità con i driver di storage (nvme, virtio, multipath) e con le release firmware; alcune variazioni di latenza dipendono da driver o firmware e non sono correggibili con sysctl.

Indicazioni architetturali

• NUMA: posizionate DB‑Threads, Page‑Cache e file di dati preferibilmente nella stessa NUMA‑Domain; un’affinità errata aumenta il traffico tra nodi.
• DB‑Konfiguration: allineate shared_buffers/innodb_buffer_pool in modo che Host‑Page‑Cache e DB‑Cache non siano in conflitto; questo riduce reclaim inutili.
• Cloud/Managed DB: nei servizi gestiti le impostazioni del kernel spesso non sono disponibili — scegliete invece classi di instance appropriate, Provisioned IOPS o opzioni di storage specializzate.

Integrazione operativa e CI

Automatizzate i test nella vostra pipeline: eseguite fio/pgbench‑run come parte delle release‑pipeline su una flotta Canary ridotta e integrate il confronto dei risultati (p50/p95/p99) nel reporting CI. Versionate sysctl.d, udev‑Rules und systemd‑Units nel Configuration‑Repository e deployate in modo idempotente con Ansible/Chef.

Checklist per il monitoring

• Alert per PSI‑Memory > soglia definita (es. 100ms) e per swap‑out persistenti.
• Monitoraggio delle tendenze: latenze p99, iowait, await e kernel OOM‑Events.
• Audit: verificate i Kernel‑Parameter e le Udev‑Regeln mediante Configuration‑Drift‑Scan.

Queste prospettive operative assicurano che Kernel‑Tuning rimanga parte di un affidabile Change‑Management per il vostro paesaggio di software aziendale personalizzato e non provochi effetti collaterali inattesi.

Per questo tema sono importanti anche la disattivazione di Transparent Hugepages e gli I/O‑Scheduler Mq-Deadline, Bfq, None. L’articolo inquadra questi aspetti in modo chiaro e mostra ciò che conta nella pratica quotidiana.