PostgreSQLLa base de données la plus sophistiquée au monde.

24. Surveiller l'activité de la base de données

Un administrateur de bases de données se demande fréquemment : « Que fait le système en ce moment ? » Ce chapitre discute de la façon de le savoir.

Plusieurs outils sont disponibles pour surveiller l'activité de la base de données et pour analyser les performances. Une grande partie de ce chapitre concerne la description du récupérateur de statistiques de PostgreSQL™ mais personne ne devrait négliger les programmes de surveillance Unix standards tels que ps, top, iostat et vmstat. De plus, une fois qu'une requête peu performante a été identifiée, des investigations supplémentaires pourraient être nécessaires en utilisant la commande EXPLAIN de PostgreSQL™. La Section 13.1, « Utiliser EXPLAIN » discute de EXPLAIN et des autres méthodes pour comprendre le comportement d'une seule requête.

24.1. Outils Unix standard

Sur la plupart des plateformes, PostgreSQL™ modifie son titre de commande reporté par ps de façon à ce que les processus serveur individuels puissent être rapidement identifiés. Voici un affichage d'exemple :

$ ps auxww | grep ^postgres
postgres   960  0.0  1.1  6104 1480 pts/1    SN   13:17   0:00 postmaster -i
postgres   963  0.0  1.1  7084 1472 pts/1    SN   13:17   0:00 postgres: stats buffer process   
postgres   965  0.0  1.1  6152 1512 pts/1    SN   13:17   0:00 postgres: stats collector process   
postgres   998  0.0  2.3  6532 2992 pts/1    SN   13:18   0:00 postgres: tgl runbogue 127.0.0.1 idle
postgres  1003  0.0  2.4  6532 3128 pts/1    SN   13:19   0:00 postgres: tgl regression [local] SELECT waiting
postgres  1016  0.1  2.4  6532 3080 pts/1    SN   13:19   0:00 postgres: tgl regression [local] idle in transaction

(L'appel approprié de ps varie suivant les différentes plateformes, de même que les détails affichés. Cet exemple est tiré d'un système Linux récent.) Le premier processus affiché ici est le postmaster, le processus serveur maître. Les arguments affichés pour cette commande sont les mêmes qu'à son lancement. Les deux processus suivant implémentent la récupération de statistiques qui sera décrite en détail dans la section suivante (elles ne seront pas présentes si vous avez configuré le système pour qu'il ne lance pas le récupérateur de statistiques). Chacun des autres processus est un processus serveur gérant une connexion cliente. Tous ces processus restant initialisent l'affichage de la ligne de commande de la forme

postgres: utilisateur base_de_données hôte activité

L'utilisateur, la base de données et les éléments de l'hôte de connexion restent identiques pendant toute la vie de connexion du client mais l'indicateur d'activité change. L'activité pourrait être idle (c'est-à-dire en attente d'une commande du client), idle in transaction (en attente du client à l'intérieur d'un bloc de BEGIN/COMMIT) ou un nom de commande du type SELECT. De plus, waiting est attaché si le processus serveur est en attente d'un verrou détenu par un autre processus serveur. Dans l'exemple ci-dessus, nous pouvons supposer que le processus 1003 attend que le processus 1016 ait terminé sa transaction et, du coup, libère un verrou.

[Astuce]

Astuce

Solaris™ requiert une gestion particulière. Vous devez utiliser /usr/ucb/ps plutôt que /bin/ps. Vous devez aussi utiliser deux options w et non pas seulement une. En plus, votre appel original de la commande postmaster doit avoir un affichage de statut dans ps plus petit que celui fourni par les autres processus serveur. Si vous échouez dans les trois, l'affichage de ps pour chaque processus serveur sera la ligne de commande originale de postmaster.