PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Éléments clés à surveiller dans PostgreSQL - Analyse de votre charge de travail

Éléments clés à surveiller dans PostgreSQL – Analyse de votre charge de travail

Dans les systèmes informatiques, la surveillance est le processus de collecte de métriques, d'analyse, de calcul de statistiques et de génération de résumés et de graphiques concernant les performances ou la capacité d'un système, ainsi que de génération d'alertes en cas de problèmes ou de pannes inattendus nécessitant une attention ou une action immédiate. Par conséquent, la surveillance a deux utilisations :une pour l'analyse et la présentation des données historiques qui nous aident à identifier les tendances à moyen et long terme au sein de notre système et nous aident ainsi à planifier les mises à niveau, et une seconde pour une action immédiate en cas de problème.

La surveillance nous aide à identifier les problèmes et à réagir à ces problèmes concernant un large éventail de domaines tels que :

  • Infrastructure/Matériel (physique ou virtuel)
  • Réseau
  • Stockage
  • Logiciel système
  • Logiciel d'application
  • Sécurité

La surveillance est une partie importante du travail d'un DBA. PostgreSQL, traditionnellement, est connu pour être «à faible maintenance» grâce à sa conception sophistiquée, ce qui signifie que le système peut vivre avec une faible fréquentation par rapport à d'autres alternatives. Cependant, pour les installations sérieuses où la haute disponibilité et les performances sont d'une importance capitale, le système de base de données doit être régulièrement surveillé.

Le rôle du DBA PostgreSQL peut s'élever à des niveaux supérieurs au sein de la hiérarchie de l'entreprise en plus du rôle strictement technique :en dehors de la surveillance de base et de l'analyse des performances, doit être capable de repérer les changements dans les modèles d'utilisation, d'identifier les causes possibles, de vérifier les hypothèses et enfin de traduire les conclusions en termes commerciaux. Par exemple, le DBA doit être en mesure d'identifier un changement soudain dans une certaine activité qui pourrait être lié à une éventuelle menace de sécurité. Ainsi, le rôle du DBA PostgreSQL est un rôle clé au sein de l'entreprise, et doit travailler en étroite collaboration avec les autres chefs de service afin d'identifier et de résoudre les problèmes qui se posent. La surveillance est une grande partie de cette responsabilité.

PostgreSQL fournit de nombreux outils prêts à l'emploi pour nous aider à collecter et analyser des données. De plus, en raison de son extensibilité, il fournit les moyens de développer de nouveaux modules dans le système central.

PostgreSQL dépend fortement du système (matériel et logiciel) sur lequel il s'exécute. Nous ne pouvons pas nous attendre à ce qu'un serveur PostgreSQL fonctionne bien s'il y a des problèmes dans l'un des composants vitaux du reste du système. Ainsi, le rôle du DBA PostgreSQL chevauche le rôle de l'administrateur système. Ci-dessous, alors que nous examinons ce qu'il faut surveiller dans la surveillance de PostgreSQL, nous rencontrerons à la fois des variables et des métriques dépendantes du système, ainsi que des chiffres spécifiques à PostgreSQL.

La surveillance n'est pas gratuite. Un bon investissement doit y être investi par l'entreprise/organisation avec un engagement à gérer et à maintenir l'ensemble du processus de surveillance. Cela ajoute également une légère charge sur le serveur PostgreSQL. Ce n'est pas grave si tout est configuré correctement, mais nous devons garder à l'esprit que cela peut être une autre façon d'abuser du système.

Principes de base de la surveillance du système

Les variables importantes dans la surveillance du système sont :

  • Utilisation du processeur
  • Utilisation du réseau
  • Espace disque/Utilisation du disque
  • Utilisation de la RAM
  • IOPS de disque
  • Utilisation de l'espace d'échange
  • Erreurs de réseau

Voici un exemple de ClusterControl montrant des graphiques pour certaines variables PostgreSQL critiques provenant de pg_stat_database et pg_stat_bgwriter (que nous aborderons dans les paragraphes suivants) lors de l'exécution de pgbench -c 64 -t 1000 pgbench deux fois :

Nous remarquons que nous avons un pic sur les blocs lus lors de la première exécution, mais nous nous rapprochons de zéro lors de la deuxième exécution car tous les blocs se trouvent dans shared_buffers.

D'autres variables d'intérêt sont l'activité de pagination, les interruptions, les changements de contexte, entre autres. Il existe une pléthore d'outils à utiliser dans les systèmes Linux/BSD et Unix ou de type Unix. Certains d'entre eux sont :

  • ps :pour une liste des processus en cours d'exécution

  • top/htop/systat :pour la surveillance de l'utilisation du système (CPU/mémoire)

  • vmstat :pour la surveillance générale de l'activité du système (y compris la mémoire virtuelle)

  • iostat/iotop/top -mio :pour la surveillance des E/S

  • ntop :pour la surveillance du réseau

Voici un exemple de vmstat sur une machine FreeBSD lors d'une requête qui nécessite des lectures de disque et également des calculs :

procs  memory      page                         disks      faults          cpu
r b w  avm   fre   flt   re  pi  po   fr    sr  ad0 ad1  in     sy    cs us sy id
0 0 0  98G  666M   421   0   0   0   170  2281    5  0  538   6361  2593  1  1 97
0 0 0  98G  665M   141   0   0   0     0  2288   13  0  622  11055  3748  3  2 94
--- query starts here ---
0 0 0  98G  608M   622   0   0   0   166  2287 1072  0 1883  16496 12202  3  2 94
0 0 0  98G  394M   101   0   0   0     2  2284 4578  0 5815  24236 39205  3  5 92
2 0 0  98G  224M  4861   0   0   0  1711  2287 3588  0 4806  24370 31504  4  6 91
0 0 0  98G  546M    84 188   0   0 39052 41183 2832  0 4017  26007 27131  5  7 88
2 0 0  98G  469M   418   0   0   1   397  2289 1590  0 2356  11789 15030  2  2 96
0 0 0  98G  339M   112   0   0   0   348  2300 2852  0 3858  17250 25249  3  4 93
--- query ends here ---
1 0 0  98G  332M  1622   0   0   0   213  2289    4  0  531   6929  2502  3  2 95

En répétant la requête, nous ne remarquerions aucune nouvelle augmentation de l'activité du disque, car ces blocs de disque seraient déjà dans le cache du système d'exploitation. Bien que l'administrateur de base de données PostgreSQL doive être en mesure de comprendre pleinement ce qui se passe dans l'infrastructure sous-jacente où la base de données s'exécute, une surveillance plus complexe du système est généralement un travail pour l'administrateur système, car il s'agit d'un vaste sujet en soi.

Sous linux, un raccourci très pratique pour le top L'utilitaire appuie sur "C", ce qui bascule l'affichage de la ligne de commande des processus. PostgreSQL réécrit par défaut la ligne de commande des backends avec l'activité SQL réelle qu'ils exécutent en ce moment et aussi l'utilisateur.

Principes de base de la surveillance PostgreSQL

Les variables importantes dans la surveillance PostgreSQL sont :

  • Performances du cache tampon (accès au cache vs lectures de disque)
  • Nombre de commits
  • Nombre de connexions
  • Nombre de sessions
  • Points de contrôle et statistiques de bgwriter
  • Aspirateurs
  • Verrous
  • Réplication
  • Et enfin, mais non des moindres, les requêtes

Généralement, il existe deux manières dans une configuration de surveillance d'effectuer la collecte de données :

  • Pour acquérir des données via un journal
  • Acquérir des données en interrogeant le système PostgreSQL

L'acquisition de données basée sur le fichier journal dépend du journal PostgreSQL (correctement configuré). Nous pouvons utiliser ce type de journalisation pour le traitement "hors ligne" des données. La surveillance basée sur le fichier journal est la mieux adaptée lorsqu'une charge minimale sur le serveur PostgreSQL est requise et lorsque nous ne nous soucions pas des données en direct ou de l'obtention d'alertes en direct (bien que la surveillance en direct à l'aide des données du fichier journal puisse être possible, par exemple en dirigeant le journal postgresql vers syslog puis diffuser syslog vers un autre serveur dédié au traitement des journaux).

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 blanc

Collecteur de statistiques PostgreSQL

PostgreSQL fournit un riche ensemble de vues et de fonctions facilement accessibles via le sous-système Statistics Collector. Là encore, ces données sont divisées en deux catégories :

  • Informations dynamiques sur ce que fait le système en ce moment.
  • Statistiques accumulées depuis la dernière réinitialisation du sous-système de collecte de statistiques.

Vues statistiques dynamiques fournir des informations sur l'activité actuelle par processus (pg_stat_activity), l'état de la réplication physique (pg_stat_replication), l'état de veille physique (pg_stat_wal_receiver) ou logique (pg_stat_subscription), ssl (pg_stat_ssl) et vide (pg_stat_progress_vacuum).

Vues statistiques collectées fournir des informations sur les processus d'arrière-plan importants tels que l'archiveur wal, le bgwriter et les objets de base de données :tables utilisateur ou système, index, séquences et fonctions ainsi que les bases de données elles-mêmes.

Il devrait être assez évident maintenant qu'il existe plusieurs façons de catégoriser les données liées à la surveillance :

  • Par source :
    • Outils système (ps, top, iotop, etc.)
    • Fichier journal PgSQL
    • Base de données
      • Dynamique
      • Collectées
  • Par opération de base de données spécifique :
    • Cache tampon
    • Commit
    • Requêtes
    • Séances
    • Points de contrôle
    • Etc

Après avoir lu cet article et expérimenté les notions, concepts et termes présentés, vous devriez être capable de faire une matrice 2D avec toutes les combinaisons possibles. A titre d'exemple, l'activité PostgreSQL spécifique (commande SQL) peut être trouvée en utilisant :ps ou top (utilitaires système), les fichiers journaux PostgreSQL, pg_stat_activity (vue dynamique), mais aussi en utilisant pg_stat_statements une extension trouvée dans contrib (vue des statistiques collectées) . De même, des informations sur les verrous peuvent être trouvées dans les fichiers journaux de PostgreSQL, pg_locks et pg_stat_activity (présenté juste en dessous) en utilisant wait_event et wait_event_type . De ce fait, il est difficile de couvrir le vaste domaine de la surveillance de manière linéaire unidimensionnelle, et l'auteur risque de créer une confusion pour le lecteur à cause de cela. Afin d'éviter cela, nous couvrirons approximativement la surveillance en suivant le cours de la documentation officielle et en ajoutant des informations connexes si nécessaire.

Vues statistiques dynamiques

Utiliser pg_stat_activity nous sommes en mesure de voir quelle est l'activité actuelle par les différents processus backend. Par exemple, si nous exécutons la requête suivante sur des parties de table avec environ 3 millions de lignes :

testdb=# \d parts
                         Table "public.parts"
   Column   |          Type          | Collation | Nullable | Default
------------+------------------------+-----------+----------+---------
 id         | integer                |           |          |
 partno     | character varying(20)  |           |          |
 partname   | character varying(80)  |           |          |
 partdescr  | text                   |           |          |
 machine_id | integer                |           |          |
 parttype   | character varying(100) |           |          |
 date_added | date                   |           |          |

Et lançons la requête suivante, qui nécessite quelques secondes pour se terminer :

testdb=# select avg(age(date_added)) FROM parts;

En ouvrant un nouveau terminal et en exécutant la requête suivante, alors que la précédente est toujours en cours d'exécution, nous obtenons :

testdb=# select pid,usename,application_name,client_addr,backend_start,xact_start,query_start,state,backend_xid,backend_xmin,query,backend_type from pg_stat_activity where datid=411547739 and usename ='achix' and state='active';
-[ RECORD 1 ]----+----------------------------------------
pid              | 21305
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:04:35.833677+02
xact_start       | 2018-03-02 18:04:35.832564+02
query_start      | 2018-03-02 18:04:35.832564+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | background worker
-[ RECORD 2 ]----+----------------------------------------
pid              | 21187
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:02:06.834787+02
xact_start       | 2018-03-02 18:04:35.826065+02
query_start      | 2018-03-02 18:04:35.826065+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | client backend
-[ RECORD 3 ]----+----------------------------------------
pid              | 21306
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:04:35.837829+02
xact_start       | 2018-03-02 18:04:35.836707+02
query_start      | 2018-03-02 18:04:35.836707+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | background worker

La vue pg_stat_activity nous donne des informations sur le processus backend, l'utilisateur, le client, la transaction, la requête, l'état ainsi qu'une information complète sur le statut d'attente de la requête.

Mais pourquoi 3 rangées ? Dans les versions>=9.6, si une requête peut être exécutée en parallèle, ou des parties de celle-ci peuvent être exécutées en parallèle, et que l'optimiseur pense que l'exécution parallèle est la stratégie la plus rapide, alors il crée un Gather ou Rassembler Fusionner nœud, puis demande au plus max_parallel_workers_per_gather processus de travail en arrière-plan, qui par défaut est 2, d'où les 3 lignes que nous voyons dans la sortie ci-dessus. Nous pouvons distinguer le processus backend du client du travailleur en arrière-plan en utilisant le backend_type colonne. Pour que la vue pg_stat_activity soit activée, vous devez vous assurer que le paramètre de configuration système track_activities est sur. Le pg_stat_activity fournit des informations riches afin de déterminer les requêtes bloquées par l'utilisation des colonnes wait_event_type et wait_event.

Une façon plus raffinée de surveiller les relevés consiste à utiliser les pg_stat_statements contrib extension, mentionnée précédemment. Sur un système Linux récent (Ubuntu 17.10, PostgreSQL 9.6), cela peut être installé assez facilement :

testdb=# create extension pg_stat_statements ;
CREATE EXTENSION
testdb=# alter system set shared_preload_libraries TO 'pg_stat_statements';
ALTER SYSTEM
testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.

testdb=# \d pg_stat_statements

Créons une table avec 100000 lignes, puis réinitialisons pg_stat_statements, redémarrons le serveur PostgreSQL, effectuons une sélection sur cette table sur le système (encore froid), puis voyons le contenu de pg_stat_statements pour la sélection :

testdb=# select 'descr '||gs as descr,gs as id into medtable from  generate_series(1,100000) as gs;
SELECT 100000
testdb=# select pg_stat_statements_reset();
 pg_stat_statements_reset
--------------------------
 
(1 row)

testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
 shared_blks_hit | shared_blks_read
-----------------+------------------
               0 |              541
(1 row)

testdb=#

Effectuons maintenant le select * une fois de plus, puis regardons à nouveau dans le contenu de pg_stat_statements pour cette requête :

[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.

testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
 shared_blks_hit | shared_blks_read
-----------------+------------------
             541 |              541
(1 row)

Ainsi, la deuxième fois, l'instruction select trouve tous les blocs requis dans les tampons partagés de PostgreSQL, et pg_stat_statements le signale via shared_blks_hit . pg_stat_statements fournit des informations sur le nombre total d'appels d'une instruction, le total_time, min_time, max_time et mean_time, ce qui peut être extrêmement utile lorsque vous essayez d'analyser la charge de travail de votre système. Une requête lente exécutée très fréquemment doit nécessiter une attention immédiate. De même, des taux de réussite constamment faibles peuvent signifier la nécessité de revoir les shared_buffers réglage.

pg_stat_replication fournit des informations sur l'état actuel de la réplication pour chaque wal_sender. Supposons que nous ayons configuré une topologie de réplication simple avec notre principal et un serveur de secours, nous pouvons alors interroger pg_stat_replication sur le serveur principal (faire de même sur le serveur de secours ne donnera aucun résultat, sauf si nous avons configuré la réplication en cascade et ce serveur de secours spécifique sert de serveur en amont vers d'autres standbys en aval) pour voir l'état actuel de la réplication :

testdb=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 1317
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 10.0.2.2
client_hostname  |
client_port      | 48192
backend_start    | 2018-03-03 11:59:21.315524+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/3029DB8
write_lsn        | 0/3029DB8
flush_lsn        | 0/3029DB8
replay_lsn       | 0/3029DB8
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async

Les 4 colonnes sent_lsn , write_lsn , flush_lsn , replay_lsn indiquez-nous la position exacte des WAL à chaque étape du processus de réplication au niveau du standby distant. Ensuite, nous créons un trafic important sur le primaire avec une commande comme :

testdb=# insert into foo(descr) select 'descr ' || gs from generate_series(1,10000000) gs;

Et regardez à nouveau pg_stat_replication :

postgres=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 1317
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 10.0.2.2
client_hostname  |
client_port      | 48192
backend_start    | 2018-03-03 11:59:21.315524+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/D5E0000
write_lsn        | 0/D560000
flush_lsn        | 0/D4E0000
replay_lsn       | 0/C5FF0A0
write_lag        | 00:00:04.166639
flush_lag        | 00:00:04.180333
replay_lag       | 00:00:04.614416
sync_priority    | 0
sync_state       | async

Nous voyons maintenant que nous avons un délai entre le primaire et le standby représenté dans le sent_lsn , write_lsn , flush_lsn , replay_lsn valeurs. Depuis PgSQL 10.0, pg_stat_replication montre également le décalage entre un WAL récemment vidé localement et le temps qu'il a fallu pour être respectivement écrit, vidé et rejoué à distance. Voir des valeurs nulles dans ces 3 colonnes signifie que le primaire et le standby sont synchronisés.

L'équivalent de pg_stat_replication côté veille s'appelle :pg_stat_wal_receiver : 

testdb=# select * from pg_stat_wal_receiver ;
-[ RECORD 1 ]---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
pid                   | 17867
status                | streaming
receive_start_lsn     | 0/F000000
receive_start_tli     | 1
received_lsn          | 0/3163F210
received_tli          | 1
last_msg_send_time    | 2018-03-03 13:32:42.516551+00
last_msg_receipt_time | 2018-03-03 13:33:28.644394+00
latest_end_lsn        | 0/3163F210
latest_end_time       | 2018-03-03 13:32:42.516551+00
slot_name             | fbsdclone
conninfo              | user=postgres passfile=/usr/local/var/lib/pgsql/.pgpass dbname=replication host=10.0.2.2 port=20432 fallback_application_name=walreceiver sslmode=disable sslcompression=1 target_session_attrs=any

testdb=#

Lorsqu'il n'y a aucune activité et que le standby a tout rejoué, alors latest_end_lsn doit être égal à sent_lsn sur le primaire (et tous les numéros de séquence de journal intermédiaires).

Comme pour la réplication physique, dans le cas de la réplication logique, où le rôle du primaire est pris par l'éditeur, et le rôle du standby est pris par l'abonné, naturellement le rôle de pg_stat_wal_receiver est pris par pg_stat_subscription . Nous pouvons interroger pg_stat_subscription comme suit :

testdb=# select * from pg_stat_subscription ;
-[ RECORD 1 ]---------+------------------------------
subid                 | 24615
subname               | alltables_sub
pid                   | 1132
relid                 |
received_lsn          | 0/33005498
last_msg_send_time    | 2018-03-03 17:05:36.004545+00
last_msg_receipt_time | 2018-03-03 17:05:35.990659+00
latest_end_lsn        | 0/33005498
latest_end_time       | 2018-03-03 17:05:36.004545+00

A noter que côté éditeur, la vue correspondante est la même que dans le cas d'une réplication physique :pg_stat_replication .

Vues statistiques collectées

pg_stat_archiver view a une ligne qui donne des informations sur l'archiveur wal. Garder un instantané de cette ligne à intervalles réguliers vous permet de calculer la taille du trafic WAL entre ces intervalles. Il donne également des informations sur les échecs lors de l'archivage des fichiers WAL.

pg_stat_bgwriter view donne des informations très importantes sur le comportement de :

  • Le pointeur de contrôle
  • Le rédacteur de fond
  • Les backends (au service du client)

Étant donné que cette vue donne des données cumulées depuis la dernière réinitialisation, il est très utile de créer une autre table d'horodatage avec des instantanés périodiques de pg_stat_bgwriter , de sorte qu'il sera facile d'obtenir une perspective incrémentielle entre deux instantanés. Le réglage est une science (ou une magie), et il nécessite une journalisation et une surveillance approfondies ainsi qu'une compréhension claire des concepts sous-jacents et des composants internes de PostgreSQL afin d'obtenir de bons résultats, et cette vue est par où commencer, en recherchant des éléments tels que :

  • Les points de contrôle_chronométrés sont-ils la grande majorité du total des points de contrôle ? Si ce n'est pas le cas, des mesures doivent être prises, les résultats mesurés et itérer l'ensemble du processus jusqu'à ce qu'aucune amélioration ne soit trouvée.
  • Les buffers_checkpoint sont-ils une bonne majorité sur les deux autres types (buffers_clean mais surtout buffers_backend ) ? Si buffers_backend est élevé, là encore, certains paramètres de configuration doivent être modifiés, de nouvelles mesures doivent être prises et réévaluées.

Pg_stat_[user|sys|all]_tables

L'utilisation la plus élémentaire de ces vues consiste à vérifier que notre stratégie de vide fonctionne comme prévu. De grandes valeurs de tuples morts par rapport aux tuples vivants signifient un aspirateur inefficace. Ces vues fournissent également des informations sur les analyses et les récupérations seq vs index, des informations sur le nombre de lignes insérées, mises à jour, supprimées ainsi que les mises à jour HOT. Vous devez essayer de maintenir le nombre de mises à jour HOT aussi élevé que possible afin d'améliorer les performances.

Pg_stat_[user|sys|all]_indexes

Ici, le système stocke et affiche des informations sur l'utilisation de l'index individuel. Une chose à garder à l'esprit est que idx_tup_read est plus précis que idx_tup_fetch. Index non PK/non uniques avec faible idx_scan doivent être pris en compte pour la suppression, car ils ne font qu'entraver les mises à jour HOT. Comme mentionné dans le blog précédent, la sur-indexation doit être évitée, l'indexation a un coût.

Pg_station_[user|sys|all]_tables

Dans ces vues, nous pouvons trouver des informations sur les performances du cache concernant les lectures de tas de table, les lectures d'index et les lectures TOAST. Une requête simple pour compter le pourcentage d'accès et la distribution des accès sur les tables serait :

with statioqry as (select relid,heap_blks_hit,heap_blks_read,row_number() OVER (ORDER BY 100.0*heap_blks_hit::numeric/(heap_blks_hit+heap_blks_read) DESC),COUNT(*) OVER () from pg_statio_user_tables where heap_blks_hit+heap_blks_read >0)
select relid,row_number,100.0*heap_blks_hit::float8/(heap_blks_hit+heap_blks_read) as "heap block hits %", 100.0 * row_number::real/count as "In top %" from statioqry order by row_number;
   relid   | row_number | heap block hits % |     In top %      
-----------+------------+-------------------+-------------------
     16599 |          1 |  99.9993058404502 | 0.373134328358209
     18353 |          2 |  99.9992251425738 | 0.746268656716418
     18338 |          3 |    99.99917566565 |  1.11940298507463
     17269 |          4 |  99.9990617323798 |  1.49253731343284
     18062 |          5 |  99.9988021889522 |  1.86567164179104
     18075 |          6 |  99.9985334109273 |  2.23880597014925
     18365 |          7 |  99.9968070500335 |  2.61194029850746
………..
     18904 |        127 |  97.2972972972973 |  47.3880597014925
     18801 |        128 |  97.1631205673759 |  47.7611940298507
     16851 |        129 |  97.1428571428571 |   48.134328358209
     17321 |        130 |  97.0043198249512 |  48.5074626865672
     17136 |        131 |                97 |  48.8805970149254
     17719 |        132 |  96.9791612263018 |  49.2537313432836
     17688 |        133 |   96.969696969697 |  49.6268656716418
     18872 |        134 |  96.9333333333333 |                50
     17312 |        135 |  96.8181818181818 |  50.3731343283582
……………..
     17829 |        220 |  60.2721026527734 |   82.089552238806
     17332 |        221 |  60.0276625172891 |  82.4626865671642
     18493 |        222 |                60 |  82.8358208955224
     17757 |        223 |  59.7222222222222 |  83.2089552238806
     17586 |        224 |  59.4827586206897 |  83.5820895522388

Cela nous indique qu'au moins 50 % des tables ont des taux de réussite supérieurs à 96,93 % et que 83,5 % des tables ont un taux de réussite supérieur à 59,4 %

Pg_station_[user|sys|all]_indexes

Cette vue contient des informations de lecture/accès aux blocs pour les index.

Pg_stat_database

Cette vue contient une ligne par base de données. Il affiche certaines des informations des vues précédentes agrégées à l'ensemble de la base de données (blocs lus, blocs touchés, informations sur les tups), certaines informations pertinentes pour l'ensemble de la base de données (total xactions, fichiers temporaires, conflits, deadclocks, temps de lecture/écriture) , et enfin le nombre de backends actuels.

Les choses à rechercher ici sont le ratio de blks_hit/(blks_hit + blks_read) :plus la valeur est élevée, mieux c'est pour les E/S du système. Cependant, les échecs ne doivent pas nécessairement être pris en compte pour les lectures de disque car ils peuvent très bien avoir été servis par le cache du système de fichiers du système d'exploitation.

Comme pour les autres vues de statistiques collectées mentionnées ci-dessus, il convient de créer une version horodatée de la pg_stat_database visualiser et avoir une vue sur les différences entre deux instantanés consécutifs :

  • Le nombre de rollbacks augmente-t-il ?
  • Ou le nombre de xactions validées ?
  • Recevons-nous beaucoup plus de conflits qu'hier (ceci s'applique aux disponibilités) ?
  • Avons-nous un nombre anormalement élevé de blocages ?

Toutes ces données sont très importantes. Les deux premiers pourraient signifier un changement dans certains modèles d'utilisation, cela doit être expliqué. Un nombre élevé de conflits peut signifier que la réplication nécessite un réglage. Un nombre élevé de blocages est mauvais pour de nombreuses raisons. Non seulement les performances sont faibles parce que les transactions sont annulées, mais aussi si une application souffre de blocages dans une topologie à maître unique, les problèmes ne feront que s'amplifier si nous passons au multi-maître. Dans ce cas, le département d'ingénierie logicielle doit réécrire les morceaux de code qui provoquent les blocages.

Verrous

Ressources associées ClusterControl pour PostgreSQL Comment gérer et surveiller votre serveur Postgres existant Comment comparer les performances de PostgreSQL

Le verrouillage est un sujet très important dans PostgreSQL et mérite son ou ses propres blogs. Néanmoins, la surveillance de base des écluses doit être effectuée de la même manière que les autres aspects de la surveillance présentés ci-dessus. pg_locks view fournit des informations en temps réel sur les verrous actuels du système. Nous pouvons attraper les longs verrous d'attente en définissant log_lock_waits , les informations sur les longues attentes seront consignées dans le journal PgSQL. Si nous remarquons un verrouillage élevé inhabituel qui entraîne de longues attentes, comme dans le cas des blocages mentionnés ci-dessus, les ingénieurs logiciels doivent examiner tous les morceaux de code susceptibles de provoquer des blocages prolongés, par ex. verrouillage explicite dans l'application (LOCK TABLE ou SELECT … FOR UPDATE).

De la même manière que dans le cas des interblocages, un système avec des verrous courts passera plus facilement à une configuration multi-maître.