La gestion des bases de données n'est pas une mince tâche et peut facilement être frustrante sans savoir ce qui se passe sous les couvertures. Qu'il s'agisse d'essayer de savoir si de nouveaux index sont utiles, si la transaction compte sur une base de données à un moment donné ou qui est connecté à la base de données à un moment donné, les données qui permettent aux administrateurs de savoir vraiment comment leurs bases de données fonctionnent sont primordiales. Heureusement, avec PostgreSQL, ces données pour tout cela sont disponibles dans le catalogue système PostgreSQL.
Le catalogue système PostgreSQL est un schéma avec des tables et des vues qui contiennent des métadonnées sur tous les autres objets de la base de données et plus encore. Avec lui, nous pouvons découvrir quand diverses opérations se produisent, comment les tables ou les index sont accédés, et même si le système de base de données lit ou non les informations de la mémoire ou doit récupérer les données du disque.
Ici, nous allons passer en revue un aperçu du catalogue système, et souligner comment le lire et comment en extraire des informations utiles. Certaines des métadonnées sont simples, et d'autres nécessitent un peu de digestion pour générer de véritables informations utiles. Quoi qu'il en soit, PostgreSQL nous offre une excellente plate-forme pour créer toutes les informations dont nous avons besoin sur la base de données elle-même.
Le catalogue PostgreSQL
PostgreSQL stocke les informations de métadonnées sur la base de données et le cluster dans le schéma « pg_catalog ». Ces informations sont partiellement utilisées par PostgreSQL lui-même pour garder une trace des choses elles-mêmes, mais elles sont également présentées afin que les personnes/processus externes puissent également comprendre l'intérieur des bases de données.
Le catalogue PostgreSQL a une règle assez solide :regardez, ne touchez pas. Bien que PostgreSQL stocke toutes ces informations dans des tables comme le ferait n'importe quelle autre application, les données des tables sont entièrement gérées par PostgreSQL lui-même et ne doivent pas être modifiées à moins d'une urgence absolue, et même dans ce cas, une reconstruction est probablement nécessaire par la suite.
Nous passerons en revue quelques tableaux de catalogue utiles, comment lire les données et des choses intelligentes que nous pouvons faire avec les données elles-mêmes. Il y a pas mal de tables dans le catalogue que nous n'aborderons pas, mais toutes les informations pour ces différentes tables se trouvent dans la documentation officielle de PostgreSQL.
Métadonnées à l'échelle du système
Une bonne partie des tables que nous pouvons interroger dans le catalogue sont des tables "à l'échelle du système", où peu importe la base de données à laquelle nous sommes connectés, les données représentent l'ensemble du cluster, pas de base de données singulière.
Informations sur la base de données
Les informations générales de la base de données sont stockées dans pg_database et les statistiques sont stockées dans pg_stat_database.
pg_database :
postgres=# SELECT oid,* FROM pg_database WHERE datname = 'severalnines';
-[ RECORD 1 ]-+-------------
oid | 16396
datname | severalnines
datdba | 10
encoding | 6
datcollate | en_US.UTF-8
datctype | en_US.UTF-8
datistemplate | f
datallowconn | t
datconnlimit | -1
datlastsysoid | 13804
datfrozenxid | 548
datminmxid | 1
dattablespace | 1663
datacl |La table pg_database contient une ligne pour chaque base de données du cluster, y compris les trois qui sortent de la boîte (postgres, template0 et template1). Cette ligne contient des informations sur l'encodage, la limite de connexion et d'autres métadonnées de base.
Colonnes d'intérêt :
oid - L'identifiant de l'objet, qui n'apparaît pas dans une sortie de requête à moins qu'il ne soit directement référencé. Ce numéro correspondra à un répertoire dans le répertoire de données du cluster
datname - Le nom de la base de données.
datdba - Le propriétaire de la base de données, oid fait référence à pg_authid .oid.
encoding - Le codage de caractères pour cette base de données, pg_encoding_to_char() sera converti en un nom lisible.
datconnlimit - Le nombre maximum de connexions simultanées autorisées sur la base de données.
dattablespace - Le tablespace par défaut pour cette base de données, référence pg_tablespace.oid.
pg_stat_database :
postgres=# SELECT * FROM pg_stat_database WHERE datname = 'severalnines';
-[ RECORD 1 ]--+------------------------------
datid | 13805
datname | postgres
numbackends | 2
xact_commit | 477460
xact_rollback | 13
blks_read | 417
blks_hit | 16488702
tup_returned | 252376522
tup_fetched | 2637123
tup_inserted | 114
tup_updated | 3
tup_deleted | 1
conflicts | 0
temp_files | 0
temp_bytes | 0
deadlocks | 0
blk_read_time | 0
blk_write_time | 0
stats_reset | 2018-02-04 19:52:39.129052+00Ce tableau statistique est l'endroit où nous obtenons des données intéressantes et utiles. Chaque ligne de ce tableau contient des données en direct pour chaque base de données et peut être exportée périodiquement pour être suivie dans le temps si vous souhaitez surveiller les modifications.
Transactions
Les informations sur les transactions se trouvent dans les colonnes xact_commit et xact_rollback, qui contiennent respectivement le nombre de transactions validées et annulées par la base de données. Cela aidera à montrer à quel point une base de données est active, ainsi qu'à repérer les échecs possibles avec des programmes qui peuvent se tromper ou revenir en arrière à un rythme alarmant.
Accès au disque et à la mémoire
Les informations indiquant si les données sont extraites ou non du disque ou de la mémoire sont stockées dans les colonnes blks_read et blks_hit. Blks_read affiche le nombre de blocs lus par cette base de données à partir du disque, tandis que blks_hit affiche le nombre de blocs trouvés dans le cache de tampons de PostgreSQL (représenté par le paramètre shared_buffers). Étant donné que la RAM est beaucoup plus rapide que le disque, nous verrions idéalement blks_hit constamment supérieur à blks_read, et si ce n'est pas le cas, nous pouvons réévaluer notre mémoire disponible.
Tuples
Les quelques colonnes suivantes traitent des tuples. Tup_returned est le nombre de lignes renvoyées dans la base de données, qui est le nombre de lignes lues par des balayages séquentiels si elles proviennent d'une table, ou le nombre d'entrées d'index renvoyées lorsqu'elles proviennent d'un index ». Tup_fetched est le nombre de lignes extraites dans la base de données, ce qui signifie qu'elles sont le résultat d'analyses bitmap, c'est-à-dire le nombre de lignes de table extraites par des analyses bitmap si elles proviennent d'une table, ou de lignes de table extraites par de simples analyses d'index si vous utilisez un index.
Nous avons également tup_inserted, tup_updated et tup_deleted, qui représentent respectivement le nombre de tuples insérés, mis à jour et supprimés dans cette base de données. Cela aidera à comprendre comment les données entrent, changent et quittent la base de données. Étant donné que les tuples mis à jour et supprimés entraînent des lignes mortes, des valeurs élevées dans ces colonnes suggéreraient que les opérations de vide automatique soient réglées pour répondre aux besoins de l'activité de la base de données.
Conflits
Si la base de données en question est un serveur de secours, les conflits de colonnes sont pratiques pour suivre le nombre de requêtes annulées en raison de conflits avec le serveur de secours en « mode de récupération ». S'il ne s'agit pas d'un cluster de secours, cette colonne peut être ignorée.
Fichiers/données temporaires
Parfois, les requêtes devront écrire dans des fichiers temporaires. Cela peut se produire lorsque la quantité de work_mem allouée à la connexion a été épuisée et doit continuer une opération de tri sur le disque plutôt qu'en mémoire. La colonne temp_files suit le nombre de ces fichiers qui ont été créés et temp_bytes suit la taille totale de tous les fichiers temporaires utilisés. Ces données peuvent aider à informer le réglage work_mem, ou même à trouver des requêtes qui pourraient nécessiter une réécriture si la taille du fichier temporaire est trop grande.
Interblocages
La colonne des interblocages indique combien de fois un interblocage se produit. Étant donné qu'un blocage peut entraîner des erreurs pour des requêtes qui, autrement, ne seraient pas erronées, il est bon de suivre cela et de s'assurer que les applications ne se marchent pas les unes sur les autres.
Temps de lecture et d'écriture
Les colonnes blk_read_time et blk_write_time suivent le nombre total de millisecondes que les backends de la base de données passent à lire et à écrire des données, ce qui peut être utile si vous essayez de comparer/améliorer la vitesse de lecture/écriture du disque
Réinitialisation des statistiques
Cette colonne, stats_reset, affiche simplement un horodatage (avec fuseau horaire) de la dernière réinitialisation des statistiques mentionnées dans cette ligne. Une valeur nulle signifie qu'elles n'ont pas été réinitialisées depuis leur création, ou même peut-être un plantage de la base de données qui a pu effacer ces statistiques.
Points de contrôle et l'auteur d'arrière-plan
pg_stat_bgwriter
postgres=# SELECT * FROM pg_stat_bgwriter;
-[ RECORD 1 ]---------+------------------------------
checkpoints_timed | 47829
checkpoints_req | 2
checkpoint_write_time | 7323
checkpoint_sync_time | 38
buffers_checkpoint | 76
buffers_clean | 0
maxwritten_clean | 0
buffers_backend | 5
buffers_backend_fsync | 0
buffers_alloc | 440
stats_reset | 2018-02-04 19:52:34.712832+00Le cluster PostgtreSQL gère l'écriture des données sur le disque de plusieurs manières différentes. En termes de «tampons sales» (données en mémoire qui ont été modifiées depuis la lecture à partir du disque, mais qui n'ont pas encore été écrites sur le disque), cela se fait soit par un point de contrôle, soit par l'enregistreur d'arrière-plan. Étant donné qu'un tampon sale doit être écrit sur le disque avant de pouvoir être libéré ou réalloué, il est crucial de s'assurer que ces processus sont réglés avec précision, et ce tableau aide à comprendre comment tout cela fonctionne.
Points de contrôle
Un point de contrôle se produit soit dans les délais (représenté par le paramètre checkpoint_timeout), soit lorsque le nombre maximum de fichiers WAL a été utilisé depuis le dernier point de contrôle, et doit forcer un point de contrôle. Dans tous les cas, un point de contrôle écrit des tampons sales sur le disque et il y a quatre colonnes qui le suivent.
Les colonnes checkpoints_timed et checkpoints_req indiquent le nombre de points de contrôle programmés (chronométrés) et le nombre de points de contrôle demandés (également appelés forcés). Une valeur d'escalade élevée de checkpoint_req pourrait suggérer une valeur max_wal_size insuffisante.
Les colonnes checkpoint_write_time et checkpoint_sync_time enregistrent le temps total (en millisecondes) passé par le processus de point de contrôle à écrire et à synchroniser sur le disque.
Enfin, buffers_checkpoint est le nombre total de tampons écrits sur le disque par les points de contrôle.
Rédacteur de fond
L'éditeur d'arrière-plan est un processus distinct qui écrit des tampons sales sur le disque, ce qui réduit idéalement la quantité de travail que le pointeur de contrôle doit effectuer.
La colonne buffers_clean représente le nombre de tampons écrits sur le disque par le processus d'arrière-plan. Comparé à buffers_checkpoint, il montre la quantité de charge de travail gérée par chaque processus (avec la connaissance supplémentaire que l'auteur d'arrière-plan a la possibilité d'écrire des tampons plusieurs fois s'ils changent souvent, contre moins fréquemment avec un point de contrôle chronométré).
Maxwriter_clean représente le nombre de fois où l'écrivain d'arrière-plan a atteint le nombre maximum de pages à vider à chaque exécution (contrôlé par le paramètre bgwriter_lru_maxpages).
Tampons en général
Les colonnes restantes nous montrent les informations générales sur les tampons, avec buffers_backend étant le nombre de tampons qu'un backend a dû écrire lui-même, au lieu d'écrire en arrière-plan ou de pointeur de contrôle, buffers_backend_fsync est le nombre de fois qu'un backend a dû exécuter son propre appel fsync, et buffers_alloc montre le nombre de tampons qui ont été alloués en général.
Activité de la base de données et verrous
Il y a deux vues qui montrent l'activité actuelle de l'utilisateur, pg_stat_activity et pg_locks. Lorsqu'ils sont interrogés, ceux-ci affichent des informations sur les connexions actuelles aux bases de données, et quel type de verrous ils ont sur quelles relations.
pg_stat_activity
postgres=# SELECT * FROM pg_stat_activity;
-[ RECORD 1 ]----+--------------------------------
datid | 13805
datname | severalnines
pid | 29730
usesysid | 10
usename | postgres
application_name | psql
client_addr |
client_hostname |
client_port | -1
backend_start | 2018-07-21 02:29:48.976588+00
xact_start | 2018-07-21 02:30:03.73683+00
query_start | 2018-07-21 02:30:03.73683+00
state_change | 2018-07-21 02:30:03.736835+00
wait_event_type |
wait_event |
state | active
backend_xid |
backend_xmin | 559
query | SELECT first_name FROM customers WHERE customers_sid = 472;
backend_type | client backendInformations générales
La vue pg_stat_activity affiche une ligne pour chaque connexion à la base de données, et quelques informations de base à ce sujet. La colonne datname représente la base de données à laquelle la connexion est réellement connectée, pid est l'ID de processus de la connexion sur l'hôte de la base de données lui-même, et usesysid et usename représentent l'utilisateur de la base de données connecté.
Pour la source du client, client_addr est l'adresse IP de l'hôte d'où provient la connexion, null signifie qu'il s'agit d'une connexion socket unix locale.
Horodatages
Il y a quatre colonnes d'horodatage qui indiquent quand certaines choses ont commencé :backend_start est le moment où la connexion a été réellement établie, xact_start est le moment où la transaction en cours a commencé (null si le client n'a pas de transaction ouverte), query_start est le moment où la requête actuelle ou la plus récente a démarré, et state_change est l'heure à laquelle l'état de la connexion a changé pour la dernière fois.
État de la connexion
Les derniers bits de pg_stat_activity couvrent l'état réel de la connexion. Si la requête attend qu'un autre libère les verrous, wait_event_type contient des informations sur le type d'événement d'attente dont il s'agit, et la colonne wait_event affichera le nom de l'événement d'attente. C'est une longue liste, mais vous trouverez plus d'informations dans la documentation de PostgreSQL.
Enfin, la colonne "état" indique dans quel état se trouve la connexion actuelle, comme active, inactive, inactive dans la transaction, et la colonne de requête indique la requête en cours d'exécution ou la plus récente.
pg_lock
SELECT * FROM pg_locks;
-[ RECORD 1 ]------+----------------
locktype | virtualxid
database |
relation |
page |
tuple |
virtualxid | 3/475862
transactionid |
classid |
objid |
objsubid |
virtualtransaction | 3/475862
pid | 29730
mode | ExclusiveLock
granted | t
fastpath | tLa table pg_locks fonctionne main dans la main avec pg_stat_activity si vous examinez l'activité des requêtes. Chaque fois qu'un verrou est posé sur une relation, cette information est stockée dans pg_locks. En utilisant le pid de pg_stat_activity, nous pouvons interroger pg_locks pour voir sur quelles relations une connexion peut avoir des verrous, de quels types de verrous il s'agit et si les verrous ont été accordés ou non.
Les colonnes les plus importantes sont 'pid', qui correspond au pid de pg_stat_activity, 'relation' qui correspond à l'OID de pg_class, 'mode' indiquant le nom du mode de verrouillage détenu et 'granted' qui indique si le verrouillage est activé ou non. la question a été acceptée.
Informations de réplication
Étant donné que PostgreSQL a intégré des fonctionnalités de réplication, il existe quelques vues qui éclairent les performances et l'état de la réplication elle-même.
Afficher pg_stat_replication : contient une ligne pour chaque processus expéditeur WAL, contenant des informations sur son état, l'emplacement des fichiers WAL sur lesquels il travaille et les informations de connexion de l'hôte de secours qui reçoit les données WAL pour la réplication.
Afficher pg_stat_wal_receiver : Si le cluster est en veille, il contiendra une seule ligne affichant des statistiques sur le processus récepteur de l'hôte.
Afficher pg_stat_subscription : Si vous envoyez des données WAL à un nœud de secours, chaque ligne ici représentera cet abonnement et contiendra des informations sur l'état des abonnements.
Afficher pg_replication_slots : Contient une liste de tous les emplacements de réplication qui existent sur le cluster et leur état actuel.
Métadonnées spécifiques à la base de données
À l'intérieur de chaque base de données, il existe une collection de tables de catalogue contenant des informations spécifiques à la base de données interrogée. Si nous recherchons des données spécifiques à partir de ces tables, nous devons nous assurer que nous sommes connectés à la bonne base de données lorsque nous émettons les requêtes.
C'est là que le cœur de l'analyse des données peut entrer en jeu, où nous pouvons voir comment nos données utilisateur sont consultées. Des tables aux index, en passant par les séquences, les requêtes qui entrent dans la base de données et récupèrent ou modifient les données, leurs actions et leur impact seront stockés dans ces tables, et nous pouvons examiner ces informations pour prendre des décisions éclairées sur la gestion de la base de données. route.
Métadonnées du tableau
Les métadonnées sur nos tables utilisateur sont stockées dans les deux tables suivantes, et elles ont chacune une ligne pour chaque table utilisateur créée dans le système. La table pg_stat_user_tables contient des statistiques sur l'accès des utilisateurs à la table, tandis que pg_statio_user_tables contient des statistiques d'E/S pour chaque table.
REMARQUE :Les données ici ne sont pas toujours parfaites à 100 % et dépendent d'analyses fréquentes des tableaux pour être correctes. L'analyse automatique couvre cela, mais un bon réglage du processus d'analyse automatique afin qu'il puisse conserver de bonnes statistiques sur chaque table. Si les statistiques semblent fausses, l'exécution manuelle d'une ANALYSE sur la table les actualisera.
Tableau pg_stat_user_tables :
severalnines=> SELECT * FROM pg_stat_user_tables WHERE schemaname = 'public' AND relname = 'history';
-[ RECORD 1 ]-------+---------
relid | 2766788
schemaname | public
relname | history
seq_scan | 13817
seq_tup_read | 466841
idx_scan | 12251
idx_tup_fetch | 127652
n_tup_ins | 11
n_tup_upd | 13
n_tup_del | 3
n_tup_hot_upd | 13
n_live_tup | 3
n_dead_tup | 21
n_mod_since_analyze | 19
last_vacuum |
last_autovacuum |
last_analyze |
last_autoanalyze |
vacuum_count | 0
autovacuum_count | 0
analyze_count | 0
autoanalyze_count | 0Pour nos statistiques de table d'utilisateurs, nous avons pas mal de données.
Méthodes d'accès aux tableaux
Lorsque les clients accèdent aux données de la table, ils le font directement ou via des index. La colonne « seq_scan » compte le nombre de balayages séquentiels reçus par la table et « seq_tup_read » compte le nombre de tuples lus via ce processus. La colonne "idx_scan" compte le nombre de fois qu'un index de la table a été utilisé pour récupérer des données.
Activité de tuple de table
Nous avons maintenant une poignée de colonnes qui comptent différentes activités sur le tableau.
‘n_tup_ins’ suit le nombre de tuples insérés
‘n_tup_upd’ suit le nombre de tuples mis à jour
'n_tup_del' suit le nombre de tuples supprimés
État du tuple de table
En raison des mises à jour et des suppressions, il peut y avoir des tuples morts qui ne sont plus des données actives, et le processus de vide finira par les libérer. Les colonnes 'n_tup_ins' et 'n_tup_ins' suivent le nombre de tuples vivants et morts, respectivement. Lorsque les tuples morts atteignent un certain point, un autovacuum sera lancé, en fonction des paramètres d'autovacuum.
Activité de vide de table
La maintenance des tables est effectuée via VACUUM ou AUTOVACUUM, et les statistiques sont collectées via ANALYZE ou AUTOANALYZE. Les quatre colonnes suivantes contiennent les dates de la dernière exécution de chacune de ces opérations :"last_vacuum", "last_autovacuum", "last_analyze", "last_autoanalyze".
Nous avons également quatre colonnes plus pratiques qui comptent simplement combien de fois les actions précédentes se produisent. En les utilisant, nous pouvons voir quelles tables obtiennent le plus d'activité :"vacuum_count", "autovacuum_count", "analyze_count" et "autoanalyze_count".
Tableau pg_statio_user_tables :
severalnines=> SELECT * FROM pg_statio_user_tables WHERE schemaname = 'public' AND relname = history;
-[ RECORD 1 ]---+---------
relid | 2766788
schemaname | public
relname | history
heap_blks_read | 4
heap_blks_hit | 63081
idx_blks_read | 5
idx_blks_hit | 44147
toast_blks_read | 0
toast_blks_hit | 0
tidx_blks_read | 0
tidx_blks_hit | 0La sortie d'E/S est utile pour aider à comprendre comment les données sont accessibles sous les couvertures. La colonne 'heap_blks_read' représente le nombre de blocs de disque lus pour cette table, et 'heap_blks_hit' représente les blocs de tampon lus à partir de la mémoire sur cette table. Ceci est utile pour savoir si les requêtes accédant à la table doivent constamment aller sur le disque ou extraire les données de la mémoire.
Les statistiques d'index sur le tableau affichent les mêmes informations avec les colonnes "idx_blks_read" et "idx_blks_hit".
Enfin, si la table contient des tables TOAST, les colonnes "toast_blks_hit" et "toast_blks_read" suivent les tables toast, tandis que "tdix_blks_read" et "tdix_blks_read" suivent les index sur ces tables toast.
Métadonnées d'index
pg_stat_user_indexes
severalnines=> SELECT * FROM pg_stat_user_indexes WHERE indexrelname = 'history_pkey';
-[ RECORD 1 ]-+-------------
relid | 2766797
indexrelid | 2766934
schemaname | public
relname | history
indexrelname | history_pkey
idx_scan | 43910
idx_tup_read | 98147
idx_tup_fetch | 98147Tout comme les homologues de table, cette table contient des informations sur les index en particulier. Une ligne par index, ce tableau montre combien de fois l'index a été parcouru avec la colonne "idx_scan", combien de tuples ont été lus avec "idx_tup_read" et combien de lignes actives ont été effectivement récupérées avec "idx_tup_fetch".
pg_statio_user_indexes
severalnines=> SELECT * FROM pg_statio_user_indexes WHERE indexrelname = 'history_pkey';
-[ RECORD 1 ]-+-------------
relid | 2766797
indexrelid | 2766934
schemaname | public
relname | history
indexrelname | history_pkey
idx_blks_read | 2
idx_blks_hit | 49380Pour pg_statio_user_indexes, les deux colonnes disponibles pour les données sont "idx_blks_read" et "idx_blks_hit", représentant le nombre de blocs lus depuis le disque et depuis la mémoire.
Téléchargez le livre blanc aujourd'hui PostgreSQL Management &Automation with ClusterControlDécouvrez ce que vous devez savoir pour déployer, surveiller, gérer et faire évoluer PostgreSQLTélécharger le livre blancQue pouvons-nous faire avec ces données ?
Faire preuve de créativité! Si les requêtes vers une table spécifique semblent être extrêmement lentes, suivez son activité au fil du temps, regardez combien d'analyses séquentielles elle obtient par rapport aux analyses d'index, regardez si elle va sur le disque ou la mémoire pour les données.
Si une grande table continue d'être fréquemment vidée automatiquement, suivez les tuples vivants et morts au fil du temps, peut-être qu'elle a spécifiquement besoin d'être modifiée pour qu'elle puisse se terminer plus rapidement, ou même peut-être que la table est candidate au partitionnement.
Comme nous pouvons voir quand les données proviennent du disque ou de la mémoire, nous pouvons créer un ratio mémoire/disque au fil du temps, en indiquant si à tout moment le ratio baisse au cours de la journée.
La quantité de tables que nous avons couvertes a couvert les gros frappeurs, les principales données qu'il est utile de connaître sur le fonctionnement interne des bases de données. Cependant, il existe de nombreuses autres tables dans le catalogue système qui contiennent des données utiles en fonction de la situation. La lecture d'autres tableaux comme précédemment aidera à fournir des informations sur la santé de la base de données en général.
Pour plus d'informations sur les tables ou les vues du catalogue PostgreSQL, consultez la documentation officielle ici, ainsi que des informations sur le collecteur de statistiques ici.
