Comment diagnostiquer un incident PostgreSQL en moins de 5 minutes (cas réel)

Objectif

Dans un environnement où chaque seconde compte, un ralentissement PostgreSQL peut coûter cher : perte de performance, saturation CPU, requêtes bloquées, utilisateurs frustrés, incidents en cascade. Pourtant, diagnostiquer la cause racine d'un problème PostgreSQL ne devrait jamais prendre des heures.

Cet article présente un cas réel de diagnostic de performance PostgreSQL réalisé à l'aide d'un système de snapshots légers. L'objectif : identifier la cause racine d'un ralentissement majeur en moins d'une minute, grâce à un rapport clair, structuré et immédiatement actionnable.

Capturer deux snapshots

Un snapshot PostgreSQL est une photo instantanée de l'activité de la base à un moment donné. Chaque snapshot capture : les statistiques des requêtes, les métriques CPU / IO, les sessions actives, les locks, les wait events et la charge globale du serveur. C'est une image figée de l'état de PostgreSQL à un instant T.

On capture plusieurs snapshots de la base à différents moments. Lorsqu'un incident survient, on sélectionne les deux snapshots autour du problème (ici 108 et 109). En les comparant, on génère automatiquement un rapport PWR qui révèle ce qui a changé et identifie la cause racine du ralentissement.

Cas concret : apparition d'un ralentissement

Pour comprendre ce qui s'est passé, on sélectionne deux snapshots : le Snapshot A, capturé juste avant que le problème n'apparaisse, et le Snapshot B, capturé au moment où la charge augmente.

Ces deux snapshots représentent deux états distincts du système. En les comparant, on peut immédiatement voir quelles requêtes ont augmenté en coût, quels utilisateurs ont généré la charge, si le CPU ou l'IO ont été saturés, si des locks ou des wait events sont apparus, si des sessions ont été bloquées, et quels objets ou index ont été sollicités de manière anormale.

Le système génère ensuite un rapport PWR à partir de ces deux snapshots, permettant d'identifier la cause racine du ralentissement.

Interprétation des métriques

Après comparaison des deux snapshots, plusieurs indicateurs montrent que le ralentissement ne vient pas d'un problème de connexions, mais bien d'une ou plusieurs requêtes très coûteuses.

Sessions : pas de saturation. Sessions actives 22/100, pas de sessions bloquées en masse -> le nombre de connexions n'est pas la cause du problème.

CPU : surcharge confirmée. Charge CPU observée : 32% de la capacité maximale -> trop élevé pour PostgreSQL sur une période courte -> indice clair d'une requête gourmande en CPU.

DB Time > Elapsed Time. DB Time : 31.40 min, Elapsed Time : 11.42 min -> la base passe plus de temps à exécuter des requêtes qu'à attendre -> cela confirme une surcharge CPU, pas un problème de sessions ou de locks.

Sessions bloquées et conclusion intermédiaire

Sessions bloquées : 1 seule session bloquée -> pas de contention significative -> le problème est ailleurs.

Conclusion intermédiaire : les métriques convergent toutes vers la même conclusion — le ralentissement provient d'une ou plusieurs requêtes très coûteuses. Pour confirmer, on analyse les sections "Top Queries par temps moyen d'exécution (CPU)", "Top CPU Queries" et "Top Cache Memory Queries" du rapport. Dans les trois catégories, la même requête apparaît en tête.

Requête fautive identifiée

La requête SELECT * FROM pgbench_accounts WHERE aid <= $1 ORDER BY abalance ... domine toutes les métriques : Top CPU, Top Mean Exec Time, Top Cache Misses, Top IO (rows), et Top dans les deltas entre snapshots. C'est la requête responsable du ralentissement.

Cause racine

Cette requête combine un filtre sur aid et un tri sur abalance. Sans index composite, PostgreSQL doit scanner une grande partie de la table, trier un volume important de lignes, consommer énormément de CPU, saturer le cache, et ralentir toutes les autres requêtes.

Résultat : problème résolu en moins de 5 minutes

Après déploiement d'un index composite adapté : CPU passé de 32% à 8%, DB Time revenu sous l'Elapsed Time, sessions stables, plus de saturation cache, requête optimisée, incident totalement résolu.

Diagnostic + correction en moins de 5 minutes.

Conclusion

Ce cas réel montre qu'un diagnostic PostgreSQL ne doit pas être long, complexe ou incertain. Avec deux snapshots légers et un rapport PWR orienté "cause racine", il devient possible d'identifier immédiatement la requête fautive, comprendre ce qui a changé, et appliquer une correction efficace en quelques minutes.

Une approche simple, rapide et reproductible — idéale pour les équipes DBA, DevOps et SRE qui doivent agir vite et avec précision.