Téléchargement du traqueur pour PostgreSQL 12, 13, 14, 15, 16, 17
Téléchargement du traqueur pour PostgreSQL 11
Téléchargement du traqueur pour PostgreSQL 10
Téléchargement du traqueur pour PostgreSQL 9.6
Téléchargement du traqueur pour PostgreSQL 9.5
Téléchargement du traqueur pour PostgreSQL 9.4
Téléchargement du traqueur pour PostgreSQL 9.3
Journal des changements
Signalement de bugs via le forum
Licence identique à celle de PostgreSQL, open source type BSD
Dossier des versions
Dans cet article, nous allons simuler un problème massif de verrouillage. Une session va bloquer une autre session qui va bloquer 500 sessions.
Démonstration avec PostgreSQL 10 :
Le décor est planté. La situation qui est décrite par les utilisateurs est une situation de blocage complet, pas un simple ralentissement.
Plutôt que de lancer le traqueur par défaut, nous allons donc utiliser une fonctionnalité introduite en 0.12.00 consistant à faire un unique cliché avec -d 0. Le chronométrage de psql est par ailleurs activé afin de connaître la durée de la requête principale :
Lanalyse a mis entre 16 et 18 secondes et donne bien lunique coupable quel que soit langle utilisé pour afficher les résultats, le process 6584. Une exécution du traqueur par défaut aurait pris 15min et aurait donné les mêmes résultats, nhésitez pas à interromptre le traqueur avec CTRL+C si la durée danalyse est anormale. Relancez-la ensuite avec -d 0.
Le niveau de récursivité utilisé par défaut pour déterminer les bloqueurs finaux est 2. La requête hiérarchique utilisée par le traqueur part des bloqueurs finaux. Il est donc possible de baisser le niveau de récursivité afin dobtenir plus rapidement le ou les coupables. Démonstration avec un niveau de 1 (-i 1) :
Lanalyse a pris 1s5 (moins de 1 seconde pour la requête principale) au lieu de 18s. Différence : les résultats sont moins précis puisque tous les bloqués ne sont plus associés à leur bloqueur final au niveau des résultats.
PostgreSQL 9.6 apporte une fonction pg_blockings_pid(pid) qui peut également être utilisée. La traque des bloqueurs finaux est essentielle donc la méthode actuelle sera conservée au moins jusque la fin de vie de la 9.5.
Il faut également noter que pg_blockings_pids ne donne de toute façon pas directement les bloqueurs finaux. Démonstration en filtrant sur un seul process via loption -w et en ajoutant pg_blockings_pid(pid) au niveau de la liste des colonnes via loption -o :
pg_blockings_pids donne une longue liste de process constituant les bloqueurs directs du processs 11138. Tous ces process ne sont cependant pas coupables car ils sont eux-mêmes bloqués par le process 6584 et pg_blocking_pids ne vous donnera pas cette information. Le traqueur conserve donc toute son utilité dans la traque des bloqueurs finaux même en 9.6 et versions supérieures de PostgreSQL.