Clever Geek Handbook

Quoi de neuf en termes de surveillance dans PostgreSQL 14

Bonjour à tous, PostgreSQL 14 beta est sorti cette semaine. Dans ce court article, je vais vous donner un bref aperçu des nouveautés et des utiles en termes de monitoring et de surveillance.



En théorie, le message devrait intéresser ceux qui ne sont pas indifférents au sujet de la surveillance et de la recherche de problÚmes dans PostgreSQL - administrateurs systÚme, DBA, SRE, DBRE.



  1. Dans pg_stat_activity ajoutĂ© un nouveau champ query_id. Le champ contient l'ID de demande similaire Ă  celui de pg_stat_statements . Ainsi, en utilisant un trio de champs datid / userid / query_id, vous pouvez attacher pg_stat_statements et afficher les statistiques accumulĂ©es pour un type spĂ©cifique de requĂȘte. Une nuance amusante - les noms des champs pour la fusion entre pg_stat_activity et pg_stat_statements sont diffĂ©rents.



    Attention, texte 
    select a.*, s.* from pg_stat_activity a inner join pg_stat_statements s on (a.datid = s.dbid AND a.usesysid = s.userid AND a.query_id = s.queryid) where a.pid = 1001291;

-[ RECORD 1 ]-------+-----------------------------------------------------------
datid               | 16413
datname             | pgbench
pid                 | 1001291
leader_pid          | 
usesysid            | 10
usename             | postgres
application_name    | pgbench
client_addr         | 
client_hostname     | 
client_port         | -1
backend_start       | 2021-05-22 10:15:57.299468+05
xact_start          | 2021-05-22 10:16:25.566151+05
query_start         | 2021-05-22 10:16:25.566623+05
state_change        | 2021-05-22 10:16:25.566763+05
wait_event_type     | 
wait_event          | 
state               | idle in transaction
backend_xid         | 237577
backend_xmin        | 
query_id            | 2517686606037258902
query               | SELECT abalance FROM pgbench_accounts WHERE aid = 1715456;
backend_type        | client backend
userid              | 10
dbid                | 16413
toplevel            | t
queryid             | 2517686606037258902
query               | SELECT abalance FROM pgbench_accounts WHERE aid = $1
plans               | 0
total_plan_time     | 0
min_plan_time       | 0
max_plan_time       | 0
mean_plan_time      | 0
stddev_plan_time    | 0
calls               | 209439
total_exec_time     | 4251.98569499987
min_exec_time       | 0.005414
max_exec_time       | 0.435581
mean_exec_time      | 0.020301785698938563
stddev_exec_time    | 0.005889254053319066
rows                | 209439
shared_blks_hit     | 884097
shared_blks_read    | 0
shared_blks_dirtied | 0
shared_blks_written | 0
local_blks_hit      | 0
local_blks_read     | 0
local_blks_dirtied  | 0
local_blks_written  | 0
temp_blks_read      | 0
temp_blks_written   | 0
blk_read_time       | 0
blk_write_time      | 0
wal_records         | 149
wal_fpi             | 2
wal_bytes           | 9870




  2. Pg_stat_activity affiche désormais également l'archiveur WAL dans la liste des processus. Jusqu'à présent, il n'y a pas beaucoup d'informations, donc elles ne sont pas particuliÚrement informatives et il y a place pour d'autres développements.

  3. Dans pg_stat_activity pour les processus Wal sender (participant Ă  la rĂ©plication), le champ de requĂȘte affiche la commande de protocole de rĂ©plication. Cette petite amĂ©lioration permet de suivre les commandes de rĂ©plication entre le maĂźtre et les rĂ©pliques, auparavant, cela n'Ă©tait possible que via les journaux avec le paramĂštre log_replication_commands activĂ©.

  4. Le champ waitstart a Ă©tĂ© ajoutĂ© Ă  pg_locks - l'heure Ă  partir de laquelle l'attente a commencĂ©. Le champ vous permet d'obtenir le dĂ©lai d'expiration sans attacher pg_stat_activity. D'une part, cela semble pratique, mais pour prendre le texte de la requĂȘte, vous devez toujours attacher pg_stat_activity. Mais pour une utilisation en tant que mĂ©trique, il convient tout Ă  fait. dans ce cas, le texte de la requĂȘte peut ne pas ĂȘtre intĂ©ressant.



    Ressemble à ça 
    # select pid,mode,now()-waitstart as wait_time from pg_locks where not granted;
-[ RECORD 1 ]--------------
pid       | 1068094
mode      | ShareLock
wait_time | 00:00:12.669753
-[ RECORD 2 ]--------------
pid       | 1068093
mode      | ShareLock
wait_time | 00:00:14.789208




  5. pg_stat_database. session_time, active_time, idle_in_transaction_time — , . — ( state), , () . — sessions, sessions_abandoned, sessions_fatal, sessions_killed . .

  6. pg_stat_progress_copy. COPY. 1) (pg_dump), 2) COPY, 3) /. 



    -[ RECORD 1 ]----+----------
pid              | 1068106
datid            | 16413
datname          | pgbench
relid            | 17612
command          | COPY FROM
type             | FILE
bytes_processed  | 30998528
bytes_total      | 195764221
tuples_processed | 313263
tuples_excluded  | 0




  7. pg_stat_wal — WAL. 13 . 13- pg_stat_statements . ( ). 



    -[ RECORD 1 ]----+------------------------------
wal_records      | 40811237
wal_fpi          | 1551923
wal_bytes        | 13744020096
wal_buffers_full | 509935
wal_write        | 1177449
wal_sync         | 666045
wal_write_time   | 26449.751
wal_sync_time    | 10956905.427
stats_reset      | 2021-05-21 10:33:39.009804+05




  8. — pg_stat_replication_slots. (PUBLICATIONS/SUBSCRIPTIONS, Debezium), pg_replication_slots.

  9. toplevel pg_stat_statements. pg_stat_statements , . , — . - , . .

  10. pg_stat_statements_info. — pg_stat_statements. , pg_stat_statements , . pg_stat_statements.max.

  11. pg_backend_memory_contexts — . . .

  12. , .



    pg_log_backend_memory_contexts() — , , pg_backend_memory_contexts.



    , — ( ) , , . . ( , ). , . , .

  13. pg_prepared_statements — generic_plans, custom_plans — . , .

  14. pg_get_wal_replay_pause_state(). pg_is_wal_replay_paused(). . — not paused, pause requested, paused.

  15. log_recovery_conflict_waits — WAL . , -.

  16. pg_lsn . pg_lsn WAL — . pg_lsn .



    , 
    pgbench=# select '1/8000000'::pg_lsn + 16777216;
-[ RECORD 1 ]-------
?column? | 1/9000000

pgbench=# select '1/8000000'::pg_lsn - 16777216;
-[ RECORD 1 ]-------
?column? | 1/7000000




  17. - autovacuum autoanalyze. log_autovacuum_min_duration.



    - 
    2021-05-22 10:50:48.000 +05 1005664 @ from  [vxid:4/309623 txid:0] [] LOG:  automatic vacuum of table "pgbench.public.pgbench_accounts": index scans: 1
        pages: 0 removed, 65600 remain, 0 skipped due to pins, 0 skipped frozen
        tuples: 1936414 removed, 2000605 remain, 566 are dead but not yet removable, oldest xmin: 253998
        buffer usage: 92201 hits, 108672 misses, 129131 dirtied
        index scan needed: 58623 pages from table (89.36% of total) had 1961508 dead item identifiers removed
        index "pgbench_accounts_pkey": pages: 10970 in total, 0 newly deleted, 0 currently deleted, 0 reusable
        avg read rate: 3.522 MB/s, avg write rate: 4.185 MB/s
        I/O Timings: read=392.361 write=1964.360
        system usage: CPU: user: 2.92 s, system: 1.79 s, elapsed: 241.07 s
        WAL usage: 195815 records, 72916 full page images, 308792606 bytes






C'est tout.



En conclusion, je voudrais faire une annonce de l'événement - PG Day'21 Russie aura lieu en ligne les 8 et 9 juillet . Ce sera un hangout de fans de PostgreSQL de deux jours avec 12 conférences de locuteurs nationaux et étrangers. La participation est gratuite. L'acceptation des articles est également ouverte jusqu'au 7 juin.



C'est tout, merci de votre attention!


More articles:


All Articles