28.2. Le récupérateur de statistiques

Le récupérateur de statistiques de PostgreSQL™ est un sous-système qui supporte la récupération et les rapports d'informations sur l'activité du serveur. Actuellement, le récupérateur peut compter les accès aux tables et index à la fois en terme de blocs disque et de lignes individuelles. Il conserve aussi la trace du nombre total de lignes dans chaque table ainsi que des informations sur les VACUUM et les ANALYZE pour chaque table. Il peut aussi compter le nombre d'appels aux fonctions définies par l'utilisateur ainsi que le temps total dépensé par chacune.

PostgreSQL™ est capable également de renvoyer des informations dynamiques sur ce qu'il se passe exactement dans le système en temps réel, comme la commande exacte en cours d'exécution par d'autres processus serveurs, et quels autres connexions existent dans le système. Cette fonctionnalité est indépendante du processus de récupération de données statistiques.

Les statistiques par index sont particulièrement utiles pour déterminer les index utilisés et leur efficacité.

Les vues pg_statio_ sont principalement utiles pour déterminer l'efficacité du cache tampon. Quand le nombre de lectures disques réelles est plus petit que le nombre de récupérations valides par le tampon, alors le cache satisfait la plupart des demandes de lecture sans faire appel au noyau. Néanmoins, ces statistiques ne nous donnent pas l'histoire complète : à cause de la façon dont PostgreSQL™ gère les entrées/sorties disque, les données qui ne sont pas dans le tampon de PostgreSQL™ pourraient toujours résider dans le tampon d'entrées/sorties du noyau et pourraient, du coup, être toujours récupérées sans nécessiter une lecture physique. Les utilisateurs intéressés pour obtenir des informations plus détaillées sur le comportement des entrées/sorties dans PostgreSQL™ sont invités à utiliser le récupérateur de statistiques de PostgreSQL™ avec les outils du système d'exploitation permettant une vue de la gestion des entrées/sorties par le noyau.

La vue pg_stat_activity aura une ligne par processus serveur, montrant des informations liées à l'activité courante de ce processus.

Note

Les colonnes wait_event et state sont indépendantes. Si un processus serveur est dans l'état active, il pourrait, ou non, être en attente (waiting) d'un événement. Si l'état est active et si wait_event est différent de NULL, cela signifie qu'une requête est en cours d'exécution mais que cette exécution est bloquée quelque part dans le système.

Note

Pour les tranches enregistrées par les extensions, le nom est indiqué par l'extension et peut être affiché comme wait_event. Il est tout à fait possible que l'utilisateur ait enregistré la tranche dans un des processus serveurs (en allouant de la mémoire partagée dynamique), auquel cas les autres processus serveurs n'ont pas cette information. Dans ce cas, le texte extension est affiché.

Voici un exemple de visualisation d'événements d'attente :

SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event is NOT NULL;
 pid  | wait_event_type |  wait_event
------+-----------------+---------------
 2540 | Lock            | relation
 6644 | LWLock          | ProcArrayLock
(2 rows)

La vue pg_stat_replication contiendra une ligne par processus d'envoi de WAL, montrant des statistiques sur la réplication avec le serveur standby connecté au processus. Seuls les serveurs standby directement connectés sont listés ; aucune information n'est disponible concernant les serveurs standby en aval.

Les délais rapportés dans la vue pg_stat_replication sont des mesures de temps prises pour l'écriture, le vidage sur disque et le rejeu des données récentes des WAL et pour que le serveur d'envoi soit mis au courant. Ces durées représentent le délai de validation qui a été (ou aurait été) introduit par chaque niveau de validation synchrone si le serveur distant était configuré comme un standby synchrone. Pour un standby asynchrone, la colonne replay_lag renvoit une approximation du délai avant que les transactions récentes deviennent visibles aux requêtes. Si le serveur standby a complètement rattrapé le serveur d'envoi et qu'il n'y a plus d'activité en écriture (donc plus de nouveaux enregistrements dans les journaux de transactions), les délais mesurés le plus récemment continueront à être affichés pendant un court instant, puis seront mis à NULL.

Les délais fonctionnent automatiquement pour la réplication physique. Les plugins de décodage logique pourraient émettre des messages de trace. S'ils ne le font pas, le mécanisme de trace affichera simplement une valeur NULL.

Note

Les délais rapportés ne sont pas des prédictions du temps pris par le serveur standby pour rattraper le serveur d'envoi en constatant le taux actuel de rejeu. Un tel système afficherait des temps similaires alors que de nouveaux journaux de transactions seraient générés, mais différeraient lorsque le serveur deviendrait inactif. En particulier, quand le serveur standby a complètement rattrapé le serveur d'envoi, pg_stat_replication affiche le temps pris pour écrire, vider sur disque et rejouter l'emplacement de l'enregistrement le plus récemment rapporté plutôt que zéro comme certains utilisateurs pourraient s'y attendre. Ceci est cohérent avec le but de mesurer les délais de la validation synchrone et de la visibilité des transactions pour les transactions récentes en écriture. Pour réduire la confusion pour les utilisateurs s'attendant à un autre modèle de retard, les colonnes de retard sont réinitialisées à NULL après un court moment sur un système entièrement à jour et complètement inactif. Les systèmes de supervision devraient choisir s'ils souhaitent représenter ces colonnes comme des données manquantes, des données à zéro, ou continuer à afficher la dernière valeur connue.

La vue pg_stat_wal_receiver contiendra seulement une ligne, affichant les statistiques du walreceiver du serveur de connexion.

La vue pg_stat_subscription contiendra une ligne par souscription du worker principal (avec le PID NULL si le processus worker n'est pas en cours d'exécution), et des lignes supplémentaires pour les workers gérant la copie initiale de données des tables souscrites.

La vue pg_stat_ssl contiendra une ligne par backend ou processus d'envoi de WAL, montrant des statistiques sur l'usage de SSL dans cette connexion. Elle peut être jointe à pg_stat_activity ou pg_stat_replication sur la colonne pid pour obtenir plus de détails sur la connexion.

La vue pg_stat_archiver aura toujours une seule ligne contenant les données du processus d'archivage de l'instance.

La vue pg_stat_bgwriter aura toujours une ligne unique, contenant les données globales de l'instance.

La vue pg_stat_database ne contiendra qu'une ligne pour chaque base de données dans l'instance, montrant ses statistiques globales.

La vue pg_stat_database_conflicts contiendra une ligne par base de données, montrant des statistiques au niveau de chaque base de données concernant les requêtes annulées survenant à cause de conflits avec la restauration sur des serveurs standby. Cette vue contiendra seulement des informations sur les serveurs standby, dans la mesure où aucun conflit ne survient sur les serveurs primaires.

La vue pg_stat_all_tables contiendra une ligne par table dans la base de données courante (incluant les tables TOAST), montrant les statistiques d'accès pour cette table spécifiquement. Les vues pg_stat_user_tables et pg_stat_sys_tables contiennent les mêmes informations, mais filtrent respectivement les tables utilisateurs et les tables systèmes.

La vue pg_stat_all_indexes contiendra une ligne pour chaque index dans la base de données courante, montrant les statistiques d'accès sur cet index spécifiquement. Les vues pg_stat_user_indexes et pg_stat_sys_indexes contiennent la même information, mais sont filtrées pour ne montrer respectivement que les index utilisateurs et les index systèmes.

Les index peuvent être utilisés avec un simple parcours d'index, un parcours d'index « bitmap » ou l'optimiseur. Dans un parcours de bitmap, les sorties de plusieurs index peuvent être combinées avec des règles AND ou OR, c'est pourquoi il est difficile d'associer des lecture de lignes individuelles de la table avec des index spécifiques quand un parcours de bitmap est utilisé. Ainsi donc, un parcours de bitmap incrémente le(s) valeur(s) de pg_stat_all_indexes. idx_tup_read pour le(s) index qu'il utilise, et incrémente la valeur de pg_stat_all_tables. idx_tup_fetch pour la table, mais il n'affecte pas pg_stat_all_indexes.idx_tup_fetch. L'optimiseur accède également aux index pour vérifier si des constantes fournies sont en dehors des plages de valeurs enregistrées par les statistiques de l'optimiseur car celles-ci peuvent ne pas être à jour.

Note

Les valeurs de idx_tup_read et idx_tup_fetch peuvent être différentes même sans aucune utilisation de parcours de bitmap, car idx_tup_read comptabilise les entrées d'index récupérées de cet index alors que idx_tup_fetch comptabilise le nombre de lignes vivantes rapportées de la table. Le second sera moindre si des lignes mortes ou pas encore validées sont rapportées en utilisant l'index, ou si des lectures de lignes de la table sont évitées grâce a un parcours d'index seul.

La vue pg_statio_all_tables contiendra une ligne pour chaque table dans la base de données courante (en incluant les tables TOAST), montrant les statistiques d'entrées/sorties de chaque table spécifiquement. Les vues pg_statio_user_tables et pg_statio_sys_tables contiennent la même information, mais sont filtrées pour ne montrer respectivement que les tables utilisateurs et les tables systèmes.

La vue pg_statio_all_indexes contiendra une ligne pour chaque index dans la base de données courante, montrant les statistiques d'entrées/sorties sur chaque index spécifiquement. Les vues pg_statio_user_indexes et pg_statio_sys_indexes contiennent la même information, mais sont filtrées pour ne montrer respectivement que les tables utilisateur et tables système.

La vue pg_statio_all_sequences contiendra une ligne pour chaque séquence dans la base de données courante, montrant les statistiques d'entrées/sorties pour chaque séquence spécifiquement.

La vue pg_stat_user_functions contiendra une ligne pour chaque fonction suivie, montrant les statistiques d'exécution de cette fonction. Le paramètre track_functions contrôle exactement quelles fonctions sont suivies.

SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
       pg_stat_get_backend_activity(s.backendid) AS query
    FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;