25.2. Le récupérateur de statistiques

Comme la récupération de statistiques ajoute un temps supplémentaire à l'exécution de la requête, le système peut être configuré pour récupérer ou non des informations. Ceci est contrôlé par les paramètres de configuration qui sont normalement initialisés dans postgresql.conf (voir Chapitre 17, Configuration du serveur pour plus de détails sur leur initialisation).

Le paramètre stats_start_collector doit valoir true pour que le récupérateur de statistiques soit seulement lancé. C'est la valeur par défaut et la configuration recommandée mais elle peut être désactivée si vous n'êtes pas intéressé par les statistiques et que vous souhaitez supprimer toute activité en trop (néanmoins, ce que vous sauverez sera assez restreint). Notez que cette option ne peut pas être changée alors que le serveur est en cours d'exécution.

Les paramètres stats_block_level et stats_row_level contrôlent la quantité d'informations réellement envoyée au récupérateur et détermine du coup le temps supplémentaire réclamé. Ils déterminent respectivement si un processus serveur récupère les statistiques d'accès disque au niveau bloc et celles au niveau ligne. De plus, les statistiques sur les transactions réussies et échouées par base sont récupérées si un de ces deux paramètres sont configurés.

Le paramètre stats_command_string active la surveillance de la commande en cours d'exécution par un processus serveur. Le sous-processus de récupération des statistiques n'a pas besoin d'être en cours d'exécution pour activer cette fonctionnalité.

Normalement, ces paramètres sont configurés dans postgresql.conf de façon à ce qu'ils s'appliquent à tous les processus serveur mais il est possible de les activer/désactiver sur des sessions individuelles en utilisant la commande SET (pour empêcher les utilisateurs ordinaires de cacher leur activité à l'administrateur, seuls les superutilisateurs sont autorisés à modifier ces paramètres avec SET ).

Plusieurs vues prédéfinies, listées dans le Tableau 25.1, « Vues statistiques standards », sont disponibles pour afficher les résultats de la récupération de statistiques. Autrement, vous pouvez construire des vues personnalisées en utilisant les fonctions statistiques existantes.

En utilisant les statistiques pour surveiller l'activité en cours, il est important de réaliser que l'information n'est pas mise à jour instantanément. Chaque processus serveur individuel transmet le nouveau nombre d'accès au niveau des blocs et des lignes au récupérateur juste avant l'attente d'une nouvelle commande du client ; donc une requête toujours en cours n'affecte pas les totaux affichés. De plus, le récupérateur lui-même émet un nouveau rapport une fois par PGSTAT_STAT_INTERVAL millisecondes (500, sauf si cette valeur a été modifiée lors de la construction du serveur). Donc, les totaux affichés sont bien derrière l'activité réelle. Néanmoins, l'information sur la requête en cours récupérée par stats_command_string est toujours à jour.

Un autre point important est que, lorsqu'un processus serveur se voit demander d'afficher une des statistiques, il récupère tout d'abord le rapport le plus récent émis par le processus de récupération, puis continue d'utiliser cette image de toutes les vues et fonctions statistiques jusqu'à la fin de sa transaction en cours. De façon similaire, les informations sur les requêtes en cours, quelque soit le processus, sont récupérées quand une telle information est demandée dans une transaction, et cette même information sera affichée lors de la transaction. Donc, les statistiques ne sembleront pas changer tant que vous restez dans la même transaction. Ceci est une fonctionnalité, et non pas un bogue, car il vous permet de traiter plusieurs requêtes sur les statistiques et de corréler les résultats sans vous inquiéter que les nombres aient pu changer. Mais si vous voulez voir les nouveaux résultats pour chaque requête, assurez-vous de lancer les requêtes en dehors de tout bloc de transaction.

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

À partir de la version 8.1 de PostgreSQL™, les index peuvent être utilisés soit directement soit via des « parcours de bitmap ». Dans un parcours de bitmap, les résultats de plusieurs index peuvent être combinés via des règles AND ou OR ; donc il est difficile d'associer des récupérations de lignes d'en-têtes individuelles avec des index spécifiques quand un parcours de bitmap est utilisé. Du coup, un parcours de bitmap incrémente le nombre dans pg_stat_all_indexes. idx_tup_read pour les index qu'il utilise et il incrémente le nombre pg_stat_all_tables. idx_tup_fetch pour la table, mais il n'affecte pas pg_stat_all_indexes. idx_tup_fetch .

Note

Avant PostgreSQL™ 8.1, les totaux idx_tup_read et idx_tup_fetch étaient pratiquement toujours égaux. Maintenant, ils peuvent être différents même sans considérer les parcours de bitmap parce que idx_tup_read compte les entrées d'index récupérées à partir de l'index alors que idx_tup_fetch compte les lignes actives récupérées à partir de la table ; ce dernier sera moindre si des lignes mortes ou pas-encore-validées sont récupérées en utilisant l'index.

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.

Il existe d'autres façons de regarder les statistiques. Cela se fait en écrivant des requêtes qui utilisent les mêmes fonctions d'accès aux statistiques que les vues standards. Ces fonctions sont listées dans le Tableau 25.2, « Fonctions d'accès aux statistiques ». Les fonctions d'accès par base de données prennent un OID de la base de données comme argument pour identifier la base de données du rapport. Les fonctions par table et par index prennent l'OID de la table ou de l'index (notez que seuls les tables et les index de la base de données en cours peuvent être vus par ces fonctions). Les fonctions d'accès au processus prennent le numéro d'identifiant du processus.

Note

blocks_fetched moins blocks_hit donne le nombre d'appels lancés pour la table, l'index ou la base de données ; mais le nombre réel de lectures physiques est habituellement moindre à cause des tampons du noyau.

La fonction pg_stat_get_backend_idset fournit un moyen agréable de générer une ligne pour chaque processus serveur actif. Par exemple, pour afficher les PID et les requêtes en cours pour tous les processus serveur :

SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
       pg_stat_get_backend_activity(s.backendid) AS current_query
    FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;