Optimiser les performances du swap pour les bases de données : zswap, swappiness et stratégies SSD

Optimiser la performance du swap pour les bases de données n’est pas un exercice théorique, mais un sujet opérationnel ayant des conséquences directes sur la latence, la stabilité et la récupération. Le mot‑clé est posé tôt : optimiser la performance du swap pour les bases de données signifie aligner la politique du noyau, la compression et le stockage de façon à ce que le swap serve de filet de sécurité contrôlable plutôt que de déclencheur d’effets domino. Ce guide étend le diagnostic de base par des méthodes de mesure, des tests de charge, des spécificités Kubernetes, des ordonnanceurs I/O et des étapes concrètes de mise en œuvre et de retour en arrière.

Optimiser la performance du swap pour les bases de données en pratique

De bonnes décisions reposent sur des corrélations, pas sur des observations isolées. Retenez : l’occupation du swap seule est inutilisable ; ce qui compte, ce sont l’activité, la longueur de la file d’attente et les métriques applicatives.

Outils et indicateurs complémentaires :

• iostat -xz : profondeur de file (avgqu‑sz), await et svctm indiquent une saturation.
• sar -B : fournit les tendances Swap‑In/Out sur des intervalles plus longs (important pour l’historique).
• perf top / eBPF : indique si la compression/décompression consomme du CPU.
• Métriques de base de données : latences au 99‑e percentile, latence fsync, durée des checkpoints, retard de réplication (Repl‑Lag).
• PSI (Pressure Stall Information) : mesure le temps d’attente effectif dû à la pression mémoire/IO.

# Längeres Monitoring-Snippet (30s Intervalle für 30 Minuten)
for i in {1..60}; do
  date +"%Y-%m-%d %H:%M:%S"
  vmstat 1 2 | tail -n1
  iostat -xz 1 2 | awk 'NR>6{print; exit}'
  [ -f /proc/pressure/memory ] && cat /proc/pressure/memory
  sleep 29
done

Conseil : enregistrez ces séries de mesures dans un artefact (compressed log) et placez-les sur un point d’observabilité centralisé. Ce n’est qu’ainsi que des runbooks peuvent être déclenchés automatiquement.

Tests de charge : générer une pression mémoire reproductible

Avant de modifier définitivement les paramètres du noyau, simulez la pression mémoire de façon contrôlée. Pour les bases de données, il est pertinent d’utiliser de vrais workloads (relecture de workloads OLTP) ou de travailler de façon synthétique avec stress-ng. L’objectif n’est pas de détruire le système, mais de reproduire des pics typiques.

# Beispiel: stress-ng VM-Load 75% der RAM-Größe über 5 Minuten
# Vorsicht: Auf Produktionssystemen nur in Maintenance-Window
total_kb=$(awk '/MemTotal/{print $2}' /proc/meminfo)
alloc_kb=$((total_kb*75/100))
sudo stress-ng --vm 1 --vm-bytes ${alloc_kb}K --vm-keep --timeout 300s --metrics-brief

Pendant le test, surveillez vmstat, iostat, PSI et vos métriques DB. De bons tests montrent si et quand le swap‑in commence, à quelle vitesse l’iowait augmente et si zswap lisse les pics d’I/O.

Configurations concrètes du noyau et du stockage

Les recommandations dépendent du contexte. Les exemples suivants sont des points de départ conservateurs et doivent être vérifiés dans votre environnement.

• vm.swappiness=10 pour les hôtes DB dédiés, 20–30 en environnements mixtes.
• zswap.enabled=1, zswap.compressor=lz4, zswap.max_pool_percent=10–20.
• Swap sur un device NVMe séparé ou LUN ; si ce n’est pas possible, définir des limites I/O via des cgroups.
• Pour NVMe : vérifier le scheduler (mq-deadline ou bfq) et contrôler les limites de file d’attente.

Exemple : définir et vérifier swappiness et zswap :

# Swappiness dauerhaft setzen
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-db-swap.conf
sudo sysctl --system

# zswap prüfen (aktivierung meist per kernel cmdline, prüfen aber runtime-Parameter)
cat /sys/module/zswap/parameters/enabled
cat /sys/module/zswap/parameters/compressor
cat /sys/module/zswap/parameters/max_pool_percent

Ordonnanceur I/O et tuning NVMe

Sur les anciens disques SATA, l’ordonnanceur d’E/S était un levier ; avec les solutions NVMe modernes, c’est le contrôleur qui prédomine. Néanmoins, il est possible d’améliorer les réglages sur de nombreux systèmes :

# Beispiel: Scheduler setzen (Device anpassen)
echo mq-deadline | sudo tee /sys/block/nvme0n1/queue/scheduler
# Queue depth anpassen (vorsichtig testen)
echo 128 | sudo tee /sys/block/nvme0n1/queue/nr_requests

BFQ (Budget Fair Queueing) peut aider les workloads sensibles à la latence dans des charges mixtes, mais n’est pas toujours disponible. Testez les modifications sous charge.

Kubernetes : Deep dive et guide pratique

Kubernetes traite le swap de manière historiquement RESTrictive. À partir de certaines versions de K8s, l’exploitation avec swap est possible, mais uniquement si le kubelet est explicitement configuré. Points importants :

• Le kubelet ne démarre pas par défaut si le swap est activé (le paramètre –fail-swap-on=false permet d’autoriser l’utilisation du swap).
• cgroup v2 propose memory.swap.max : vous pouvez définir séparément les limites de mémoire et de swap pour une cgroup. Cela permet des politiques granulaires pour les DB‑Pods.
• Les DB‑Pods devraient idéalement avoir Requests == Limits (QoS Guaranteed). Ainsi, le comportement mémoire est prévisible.

Exemple : définir le flag kubelet (édition de l’unité systemd) et redémarrer le nœud :

# systemd Kubelet override (Beispielpfad kann variieren)
sudo mkdir -p /etc/systemd/system/kubelet.service.d
cat <<'EOF' | sudo tee /etc/systemd/system/kubelet.service.d/10-swap.conf
[Service]
Environment="KUBELET_EXTRA_ARGS=--fail-swap-on=false"
EOF
sudo systemctl daemon-reload
sudo systemctl RESTart kubelet

Exemple cgroup v2 : définir memory.swap.max dans une cgroup (avec prudence, peut affecter tout le système) :

# cgroup Pfad anpassen; Beispiel für system.slice
echo 1073741824 | sudo tee /sys/fs/cgroup/system.slice/memory.swap.max  # 1 GiB

Dans Kubernetes, vous pouvez utiliser Pod‑QoS et les spécifications StatefulSet pour éviter que les DB‑Pods ne swapent de façon imprévisible. Documentez la politique des nœuds et le comportement de sauvegarde / basculement dans votre runbook.

Runbook : mise en œuvre progressive avec des seuils métriques (Metrik‑Gates)

Une approche sécurisée réduit le risque. Utilisez cette checklist étape par étape :

1. Baseline : collecter des métriques pendant 24–72 h (métriques DB + métriques nœud).
2. Modification de configuration 1 : définir vm.swappiness à 10 ; observer pendant 1–2 fenêtres de maintenance.
3. Modification de configuration 2 : activer zswap (paramètre de boot) avec lz4 et max_pool_percent 10–15 ; observer pendant 1–2 fenêtres de maintenance.
4. Stockage : si possible, déplacer le swap sur un NVMe séparé ou configurer du QoS.
5. Test en production simulée : effectuer un pic simulé (rejeu de charge) et vérifier les seuils métriques.
6. Déploiement en production : déploiement progressif par groupes d’hôtes (Canary Nodes) avec rollback automatique en cas de dépassement des seuils d’alerte prédéfinis.

Exemple de seuils métriques (implémentables comme AlertRules) : si en 5 minutes à la fois (a) Swap‑In > 0 KB/s de façon constante, (b) iowait > 20 %, et (c) latence DB au 99e percentile > 2× la baseline → rollback ou drain du nœud.

Commandes de rollback et mesures d’urgence

En cas de problème, il faut revenir en arrière rapidement et en toute sécurité. Voici les commandes principales :

# Swappiness zurücksetzen
sudo sysctl -w vm.swappiness=60
sudo rm /etc/sysctl.d/99-db-swap.conf || true
sudo sysctl --system

# zswap deaktivieren: Kernel-Parameter entfernen und Reboot (sauberer Weg)
# Achtung: reboot in Wartungsfenster oder redundante Hosts verwenden
# Swap temporär deaktivieren
sudo swapoff -a
# Swap wieder aktivieren nach Korrektur
sudo swapon -a

Remarque: un swapoff immédiat peut provoquer des OOMs si la RAM est insuffisante. N’utilisez swapoff que si vous êtes certain que de la mémoire est disponible ou que les charges de travail sont arrêtées.

Scénarios typiques de dépannage

Voici trois cas réels et la manière de les aborder:

Cas 1: latence soudaine après une sauvegarde nocturne

Cause: le processus de sauvegarde occupe temporairement la RAM, le noyau commence à swapper. Solution: brider le processus de sauvegarde, définir des limites, activer zswap et exécuter le swap sur un périphérique séparé.

Cas 2: Pod DB dans Kubernetes swappe malgré les Requests

Cause: politique des nœuds incohérente (nœuds avec et sans swap), Kubelet avec –fail-swap-on=false non uniforme. Solution: homogénéiser la politique des nœuds, ajuster le QoS des pods, mettre en place des alertes.

Cas 3: l’I/O de swap entre en concurrence avec le WAL sur NVMe

Cause: interférence des queues de périphérique partagées. Solution: isoler le swap ou tester BFQ/I/O‑QoS ; le cas échéant, provisionner un NVMe séparé ou une LUN de stockage.

Conclusion

Optimiser les performances du swap pour les bases de données est un exercice d’équilibre entre une résilience stable et une latence minimale. Avec une approche basée sur des mesures, un swappiness conservateur, un usage ciblé de zswap et une stratégie de stockage claire, vous obtenez une dégradation contrôlée plutôt que des pannes imprévisibles. Dans Kubernetes, vous avez en outre besoin de politiques de nœuds cohérentes et de Requests/Limits stricts pour rendre le comportement reproductible. Mettez en place des tests automatisés et des points de basculement (rollback‑gates) clairs, et considérez le tuning du swap comme une fonctionnalité opérationnelle avec fenêtres de maintenance, observabilité et runbooks documentés.

Aspects d’architecture, de virtualisation et d’exploitation souvent négligés

Sur le sujet de l’optimisation des performances de swap pour les bases de données, le travail ne s’arrête pas à swappiness ou zswap. Beaucoup de problèmes naissent à l’interface entre architecture, virtualisation et topologie de stockage. Les points pratiques suivants aident à détecter les risques cachés et à garantir la sûreté d’exploitation.

NUMA, placement des processus et pénalités de mémoire distante

Sur des systèmes multicœurs avec NUMA (Non‑Uniform Memory Access), le swapping au-delà des frontières NUMA peut entraîner une augmentation drastique de la latence : une page située sur une autre node génère non seulement de l’I/O de swap, mais aussi des accès mémoire distants. Cela concerne particulièrement les gros processus monolithiques de bases de données.

# NUMA-Topologie prüfen
numactl --hardware
# DB-Prozess an lokale Node binden (Beispiel)
numactl --cpunodebind=0 --membind=0 /usr/lib/postgresql/…

Recommandation: pour les hôtes DB, vérifier que les processus et leurs allocations mémoire résident sur la même NUMA‑node. Dans de nombreux cas, un binding CPU/mémoire statique et l’utilisation de HugePages améliorent la prévisibilité sous pression mémoire.

Swap dans les environnements virtualisés: ballooning et swap côté hôte

Les machines virtuelles masquent souvent le véritable responsable de la pression mémoire. Le ballooning KVM/virt ajuste dynamiquement l’allocation mémoire — ce qui peut conduire l’hyperviseur lui‑même à swapper. Vérifiez l’état réel de la mémoire côté hyperviseur et côté invité.

# Domänen-Speicherstatistiken (libvirt)
virsh dommemstat 
# Auf Hypervisor prüfen, ob Swapping stattfindet
sudo cat /proc/meminfo | grep -E 'Swap|MemAvailable'
sudo iostat -xz 1 3

Si un swap côté hyperviseur est constaté, les solutions sont: augmenter la RAM, désactiver le ballooning pour les VM critiques ou placer les charges de travail sur des hôtes dédiés.

Topologie de stockage: isolation des files, NVMe multipathing et placement du swap

Swap sur le même périphérique que les fichiers WAL ou de données entraîne une interférence des files d’attente. Stratégies :

• NVMe/LUN physiquement séparés pour le Swap, idéalement avec des queues de contrôleur distinctes.
• Si la séparation n’est pas possible : tester l’I/O‑QoS (BFQ, cgroup‑io) pour prioriser les I/O WAL.
• Pour le multipathing NVMe, vérifiez si la configuration multipath répartit de manière uniforme (round‑robin) et est optimisée pour les files d’attente.

Usure, durée de vie et coûts d’exploitation des SSD/NVMe

Le Swap génère de nombreux cycles d’écriture. À long terme, cela affecte la durée de vie RESTante des SSD grand public. Mettez en place la surveillance SMART et la télémétrie des périphériques :

# SMART-Report für NVMe/SSD
sudo smartctl -a /dev/nvme0n1
# Device-IO-Bytes überwachen (Prometheus node exporter oder iostat)
iostat -x 1 3

Pour les hôtes DB en production, privilégiez des NVMe Enterprise avec un DWPD plus élevé, un overprovisioning suffisant et une stratégie de Swap qui minimise les écritures (zswap, profilage de compression, limitation des écritures lors des sauvegardes).

Alerting automatique et logique d’action (exemple Prometheus)

Les mesures automatiques ne devraient pas réagir uniquement à l’occupation du Swap. Combinez les indicateurs : taux de swap-in, temps d’I/O disque et latence DB au 99e percentile. Exemple d’une Prometheus AlertRule :

groups:
- name: swap.rules
  rules:
  - alert: SwapWithHighIOWait
    expr: |
      increase(node_vmstat_pswpin[5m]) > 0
      and (avg by(instance)(irate(node_cpu_seconds_total{mode="iowait"}[1m])) > 0.2)
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "Swap activity with high iowait on {{ $labels.instance }}"
      description: "Sustained swap-in combined with elevated iowait. Consider draining node or triggering failover."

Associez les alertes à des playbooks : au déclenchement, lancer automatiquement un Canary‑Drain ou envoyer un webhook à un outil d’orchestration de runbooks ; évitez les redémarrages automatiques directs.

Remarque d’intégration : sauvegarde, HA et politique de basculement

Déterminez si la dégradation du Swap ou un basculement rapide est préférable pour vos RTO/RPO. Dans les architectures en cluster, un basculement rapide (redémarrage court) peut être préférable, car une dégradation prolongée du Swap peut provoquer des problèmes de réplication ou de consistance.

Conclusion : ne concevez pas le Swap isolément comme un paramètre noyau, mais comme partie intégrante de l’architecture globale. Documentez les décisions de placement (NUMA, politiques VM, placement du Swap), automatisez des métriques‑gates et intégrez la télémétrie matérielle dans votre monitoring. Ainsi, le Swap devient une variable opérationnelle contrôlée plutôt qu’une source d’erreurs cachée.

Gouvernance du Swap, tests et gestion du cycle de vie

Les mesures techniques ont peu d’effet si les changements ne sont pas couverts par le change‑control, le code d’infrastructure et des tests réels. Placez la kernel‑cmdline, les fichiers /etc/sysctl.d et les paramètres zswap dans votre repo IaC basé sur Git et imposez des revues. Exécutez des jobs CI automatisés qui valident la syntaxe de configuration, les modules noyau et un court smoke test sous une topologie staging‑NUMA.

Operationalisez vos déploiements : groupes canary (p. ex. 5–10 % des hôtes DB), métriques‑gates automatisés et playbook de drain orchestré réduisent le risque. Complétez les règles d’approvisionnement : spec NVMe (DWPD, overprovisioning) et cycles de remplacement doivent prendre en compte les charges de Swap, en particulier pour des logiciels d’entreprise personnalisés avec des SLA stricts de latence. Documentez également les parcours d’escalade, les fenêtres de maintenance et les responsabilités dans le runbook, afin de permettre un rollback rapide et contrôlé.

Pour ce sujet, Linux le swap et le swap sur SSD sont également importants. L’article situe ces aspects de manière compréhensible et montre ce qui importe au quotidien.