Comment lire un rapport PWR dans PostgreSQL : guide complet d'analyse des performances

Qu'est-ce qu'un rapport PWR PostgreSQL ?

Lire un rapport PWR PostgreSQL permet de comprendre rapidement d'où viennent les ralentissements d'une base de données. Ce type de rapport de performance PostgreSQL est particulièrement utile pour identifier les requêtes coûteuses, les verrous, les problèmes d'I/O disque, les saturations CPU et les anomalies de cache. Pour les équipes DBA, support et développement, le rapport PWR est un outil précieux d'audit de performance PostgreSQL.

Un rapport PWR PostgreSQL est un document d'analyse qui synthétise l'activité de la base sur une période donnée, en comparant deux snapshots (un "avant" et un "après"). Il agrège les statistiques d'exécution pour montrer les requêtes les plus coûteuses, les temps d'attente les plus importants, les sources de charge, les lectures et écritures, les verrous et les tendances de performance.

Ce type de rapport d'analyse de performance PostgreSQL aide à répondre à des questions essentielles : quelle requête ralentit la base ? Le problème vient-il du CPU, du disque ou des locks ? Y a-t-il une régression de performance ? Quelle table ou quel index consomme le plus de ressources ? La charge est-elle liée à une période précise ?

Commencer par le résumé global du rapport

La première étape pour lire un rapport PWR dans PostgreSQL consiste à analyser le résumé global (Database Environment Summary). Cette section donne une photographie immédiate de l'état de la base pendant la fenêtre observée : durée de la période analysée, nombre de sessions actives, temps total d'exécution (DB Time), répartition entre CPU, I/O et waits, activité de lecture et d'écriture.

Si le rapport montre une forte activité sur une période courte, cela peut indiquer une montée en charge applicative, une requête SQL mal optimisée, un batch lancé trop agressivement, un problème de concurrence, ou une capacité insuffisante du serveur PostgreSQL. Si au contraire l'activité reste régulière mais que les temps de réponse sont élevés, le problème est souvent plus structurel : absence d'index, mauvaise stratégie de requête, table trop volumineuse, ou configuration PostgreSQL à ajuster.

Quand considérer une base PostgreSQL en état de souffrance ?

Avant même de descendre dans le détail des requêtes, trois ratios simples — hérités de la lecture d'un rapport AWR côté Oracle — permettent de juger en quelques secondes si une base PostgreSQL souffre réellement ou si l'activité observée reste normale.

• DB Time vs Elapsed Time — DB Time est le temps cumulé passé par PostgreSQL à exécuter des requêtes sur la période ; Elapsed est la durée réelle écoulée entre les deux snapshots. Si DB Time ≈ Elapsed × nombre de cœurs CPU, la charge est lourde mais cohérente avec la capacité de la machine. Si DB Time dépasse largement ce produit, c'est le signal d'une base sous tension.
• AAS (Average Active Sessions) = DB Time / Elapsed Time — en bonne santé : AAS reste inférieur ou égal au nombre de cœurs CPU disponibles (max_worker_processes). Mauvais signe : AAS supérieur au nombre de cœurs → le système est lié au CPU ou passe son temps à attendre (I/O, locks, latches).
• Répartition CPU du temps de base — en bonne santé : 60 à 90% du DB Time consacré au CPU signifie que la base passe le plus clair de son temps à faire du travail utile. Mauvais signe : une part CPU anormalement faible indique que le temps est surtout perdu en attentes (I/O, locks, latches) plutôt qu'en calcul réel.
• Sessions bloquées et transactions longues — même une seule session bloquée de façon prolongée, ou une transaction "idle in transaction" qui traîne, peut suffire à faire dérailler des dizaines d'autres requêtes en cascade.
• Cache hit ratio en baisse — un cache hit ratio qui décroche nettement de sa valeur habituelle (par exemple sous 90% alors qu'il tourne d'ordinaire à 99%+) annonce une pression mémoire ou un changement brutal de volumétrie.

Analyser les requêtes coûteuses PostgreSQL

La section la plus importante d'un rapport PWR PostgreSQL est souvent celle des requêtes les plus coûteuses (Top Queries). Elle permet d'identifier les requêtes SQL qui consomment le plus de ressources, à partir des indicateurs de pg_stat_statements : temps total, temps moyen, nombre d'appels, lignes lues et retournées, hits sur le cache (shared buffers), lectures physiques, écritures et temps d'attente.

Une requête peut être problématique dans plusieurs cas : un temps total très élevé (elle monopolise une part importante des ressources), un temps moyen élevé (elle est lente à chaque exécution), un nombre d'appels très important (elle n'est pas forcément très lente individuellement, mais son volume la rend coûteuse), beaucoup de lectures physiques (elle ne profite pas suffisamment du cache), ou un faible ratio lignes retournées / lignes examinées (elle scanne trop de données).

Si une requête apparaît en tête du rapport avec un grand nombre d'exécutions et un temps total dominant, il faut vérifier les index utilisés, le plan d'exécution, les jointures, les filtres, les tris, les agrégations, les conversions implicites, et la sélectivité des conditions WHERE.

Comprendre les lectures, écritures et l'I/O disque PostgreSQL

L'I/O PostgreSQL est une cause très fréquente de lenteur. Le rapport PWR permet d'identifier si la base attend le disque ou si le problème vient ailleurs, à travers les lectures physiques, les lectures logiques (cache), les écritures disque, les volumes temporaires et le temps passé en attente de bloc disque.

Une requête peut sembler lente alors qu'elle est surtout pénalisée par des lectures massives, un cache insuffisant, des index absents, ou un stockage trop lent. Bon signe : les lectures logiques dominent largement, peu d'accès disque, faible volume de fichiers temporaires, latence stable. Mauvais signe : lectures physiques élevées, saturation du stockage, nombreuses écritures temporaires, temps d'attente I/O important.

Lire les verrous et blocages PostgreSQL

Les verrous PostgreSQL peuvent provoquer des ralentissements très visibles, même si les requêtes elles-mêmes sont correctes. Il faut observer les sessions en attente de lock, la durée des blocages, les transactions longues, les conflits sur une même table, les deadlocks et les chaînes de blocage.

Un rapport PWR qui montre beaucoup de temps perdu sur les verrous indique souvent des transactions ouvertes trop longtemps, des mises à jour concurrentes, des opérations de maintenance mal planifiées, ou un modèle applicatif qui bloque trop souvent les mêmes lignes. Symptômes typiques : utilisateurs qui signalent un ralentissement global, requêtes rapides en apparence mais bloquées en attente, augmentation soudaine du temps de réponse, effets en cascade sur plusieurs services.

Vérifier l'utilisation mémoire et le cache PostgreSQL

Une autre partie importante de l'audit de performance PostgreSQL concerne la mémoire : shared buffers, cache hit ratio, work_mem, usage temporaire sur disque, tri sur disque, hash join spill, volume de données en mémoire.

Lorsque le cache est efficace, PostgreSQL lit moins souvent sur disque et les temps de réponse sont meilleurs. Si le rapport montre beaucoup de lectures physiques ou de données temporaires, cela peut révéler un manque de mémoire allouée aux requêtes, des tris trop volumineux, des jointures lourdes, ou une configuration work_mem trop faible.

Lire les waits dans un rapport PWR PostgreSQL

Les wait events PostgreSQL aident à comprendre pourquoi le temps est perdu. Types de waits fréquents : CPU, I/O, lock, WAL, checkpoint, network, client, buffer, synchronization.

• Wait CPU dominant : requêtes trop complexes, trop de calcul, manque de CPU
• Wait I/O dominant : problème de disque, absence d'index, cache insuffisant
• Wait lock dominant : contention entre sessions
• Wait WAL / checkpoint : pression sur l'écriture et sur la journalisation
• Wait client / network : lenteur côté application ou réseau

Examiner les tendances de performance PostgreSQL

Un bon rapport d'analyse performance PostgreSQL ne doit pas être lu seulement à l'instant T. Il doit aussi être comparé dans le temps : évolution du temps total, progression du nombre d'appels, évolution des lectures physiques, apparitions de nouvelles requêtes coûteuses, changements de comportement après déploiement.

Une dégradation progressive peut indiquer une croissance des volumes, une dérive des requêtes, une perte d'efficacité de l'indexation, une fragmentation logique, ou une régression après livraison applicative.

Comment prioriser les actions de tuning PostgreSQL

Une fois le rapport PWR lu, il faut savoir quoi faire en premier.

• Priorité 1 — Requêtes les plus coûteuses : analyser le plan d'exécution, ajouter ou corriger des index, réécrire les jointures, réduire les scans inutiles
• Priorité 2 — Blocages et verrous : raccourcir les transactions, éviter les opérations longues en heure de pointe, corriger les conflits d'accès
• Priorité 3 — I/O disque : vérifier le stockage, réduire les lectures physiques, améliorer la sélectivité, limiter les gros tris temporaires
• Priorité 4 — Mémoire : ajuster work_mem, vérifier les hashes et tris qui débordent sur disque, surveiller les caches
• Priorité 5 — Infrastructure : CPU, RAM, disque, latence réseau, configuration système

Checklist de lecture rapide d'un rapport PWR PostgreSQL

Les questions à se poser systématiquement à la lecture d'un rapport PWR :

• Quelle requête domine le temps total ?
• Y a-t-il des lectures physiques excessives ?
• Le problème vient-il du CPU, du disque ou des verrous ?
• Les sessions sont-elles bloquées ?
• Le cache est-il efficace ?
• Y a-t-il une régression par rapport au rapport précédent ?
• Les waits indiquent-ils une contention ou une saturation ?
• La base souffre-t-elle d'un problème structurel ou ponctuel ?

Conclusion

Savoir comment lire un rapport PWR dans PostgreSQL est indispensable pour toute équipe DBA, support ou développement qui veut faire un diagnostic PostgreSQL fiable. Un bon rapport de performance PostgreSQL permet de repérer rapidement les requêtes coûteuses, les verrous PostgreSQL, les problèmes d'I/O disque, et les limites de configuration.

Avec une lecture méthodique du résumé, des requêtes SQL, des waits, des locks et des tendances, il devient beaucoup plus simple d'identifier la vraie source du ralentissement et de lancer les bonnes actions de tuning PostgreSQL. Le rapport complet utilisé dans les captures de cet article est disponible en téléchargement ci-dessous au format PDF, pour l'explorer par vous-même section par section.