Régression de performance PostgreSQL sous Linux 7.0 : ce qu'il faut vraiment faire

La panique, puis la réalité

Fin avril 2026, une annonce a fait trembler les équipes DBA et DevOps : Linux 7.0 diviserait par deux le débit de PostgreSQL. Ubuntu 26.04 LTS prévoyant d'embarquer ce noyau dès sa sortie, l'inquiétude est compréhensible. Mais avant de déclencher un plan de crise, il faut comprendre ce qui se passe réellement — et ce que vous devez concrètement faire sur vos environnements.

Cet article est un mini-playbook praticien : reproduire le problème en staging, surveiller les bonnes métriques, appliquer les mitigations immédiates. Basé sur l'analyse de Lætitia Avrot sur My DBA Notebook.

Comprendre la cause racine : HugePages, THP et rseq

Pour saisir le problème, un peu de théorie noyau s'impose.

Linux gère la mémoire en pages (4 Ko par défaut). Pour les charges lourdes comme PostgreSQL, les Huge Pages (2 Mo) réduisent la pression sur le TLB (Translation Lookaside Buffer) et améliorent significativement les performances. La configuration recommandée depuis longtemps est d'activer les Huge Pages statiques et de désactiver les Transparent Huge Pages (THP).

Le THP est une tentative d'automatisation par le noyau : il regroupe dynamiquement des pages ordinaires en Huge Pages. Le problème ? Ce processus de compaction introduit des pauses imprévisibles qui se répercutent directement sur la latence de PostgreSQL.

Linux 7.0 introduit des changements dans le scheduler (ordonnancement des processus) et dans la gestion de rseq (Restartable Sequences), un mécanisme permettant à un thread d'effectuer des opérations atomiques sans appel système. Ces changements, combinés aux comportements THP, expliquent les régressions observées dans les benchmarks — et leurs effets sont amplifiés dans les environnements conteneurisés (Docker, Kubernetes) où le contrôle du noyau est limité.

Reproduire le problème en staging

Avant tout changement en production, validez l'impact réel sur votre charge de travail.

1. Vérifier la configuration actuelle

# État des Huge Pages
cat /proc/meminfo | grep -i huge

# État du THP
cat /sys/kernel/mm/transparent_hugepage/enabled
# Si la sortie est [always] ou [madvise] → problème potentiel

# Paramètres PostgreSQL
psql -c "SHOW huge_pages;"
psql -c "SHOW shared_buffers;"

2. Lancer un benchmark de référence avec pgbench

# Initialisation (facteur d'échelle 100 ≈ 1,5 Go)
pgbench -i -s 100 mydb

# Benchmark lecture/écriture mixte — 5 minutes, 16 clients
pgbench -c 16 -j 4 -T 300 -P 10 mydb

Notez le TPS (transactions par seconde) et la latence p95. C'est votre baseline. Rejouer ce test avant/après chaque mitigation.

3. Métriques à surveiller en temps réel

# Surveiller les compactions THP en live
watch -n 2 'grep -E "thp_collapse|thp_fault" /proc/vmstat'

# CPU steal (colonne %st dans top)
vmstat 1 | awk '{print $17}'

Mitigations immédiates

Désactiver le THP (priorité absolue)

# Désactivation immédiate (non persistante)
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# Persistance via rc.local ou systemd
cat > /etc/systemd/system/disable-thp.service << '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"

[Install]
WantedBy=multi-user.target
EOF

systemctl enable --now disable-thp.service

Configurer les Huge Pages statiques

# Calculer le nombre de Huge Pages nécessaires
# shared_buffers + ~20% overhead
# Exemple : shared_buffers = 8 Go → (8192 + 1638) Mo / 2 Mo ≈ 4915 pages

echo 5000 > /proc/sys/vm/nr_hugepages

# Persistance
echo 'vm.nr_hugepages = 5000' >> /etc/sysctl.d/99-postgresql.conf
sysctl -p /etc/sysctl.d/99-postgresql.conf

Dans postgresql.conf :

huge_pages = on   # 'try' en environnement incertain

En environnement conteneurisé (Docker / Kubernetes)

Les conteneurs héritent de la configuration THP de l'hôte. La désactivation doit se faire au niveau du nœud, pas dans le conteneur.

Docker : configurer le nœud hôte comme ci-dessus, ou utiliser un init container pour les environnements managés.

Kubernetes : utiliser un DaemonSet pour appliquer la configuration sur tous les nœuds :

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: disable-thp
spec:
  selector:
    matchLabels:
      name: disable-thp
  template:
    metadata:
      labels:
        name: disable-thp
    spec:
      hostPID: true
      containers:
      - name: disable-thp
        image: alpine
        securityContext:
          privileged: true
        command:
        - /bin/sh
        - -c
        - |
          echo never > /sys/kernel/mm/transparent_hugepage/enabled
          echo never > /sys/kernel/mm/transparent_hugepage/defrag
          sleep infinity

Attention : sur les clusters managés (GKE, EKS, AKS), l'accès aux paramètres noyau des nœuds peut être limité ou soumis aux politiques de sécurité de votre organisation. Vérifiez vos droits avant d'appliquer.

Sur le patch rseq

Les distributions majeures (Red Hat, Debian, Ubuntu) intègrent généralement des correctifs en amont avant la mise à disposition des LTS. Avant de migrer vers Ubuntu 26.04 LTS, vérifiez le changelog du noyau packagé et l'existence du correctif rseq pour PostgreSQL. Ne migrez pas en production sans avoir rejoué votre benchmark pgbench sur la version cible.

Ce qu'il faut réellement surveiller à long terme

• PostgreSQL progresse de ~15 % par version majeure en moyenne depuis la version 8 : chaque mise à jour mineure ou majeure du SGBD est souvent plus impactante positivement que le bruit autour des noyaux.
• Les benchmarks synthétiques ne reflètent pas toujours votre charge réelle : rejouer vos propres requêtes critiques avec pgbench --file ou pgreplay.
• Tester les mises à jour de noyau en staging est non négociable — particulièrement avant une migration LTS en production.
• Les environnements conteneurisés nécessitent une attention particulière : la séparation entre configuration noyau hôte et workload conteneurisé est une source récurrente de régressions silencieuses.

Conclusion

La regression observée avec Linux 7.0 est réelle dans certaines configurations, mais évitable avec les bonnes pratiques. Désactiver le THP, configurer correctement les Huge Pages statiques, et adapter la configuration de vos nœuds Kubernetes ou Docker hôtes suffit dans la grande majorité des cas à retrouver les performances attendues.

L'essentiel : benchmarkez avant de migrer, surveillez les bonnes métriques, et ne laissez pas une headline vous faire paniquer. PostgreSQL reste, en 2026, l'une des bases de données les plus robustes et les mieux optimisées de l'écosystème open source.

Source originale : Lætitia Avrot — Postgres performance regression: are we there yet?