O que há de novo em termos de monitoramento no PostgreSQL 14

Olá a todos, a versão beta do PostgreSQL 14 foi lançada esta semana. Neste breve artigo, darei uma rápida visão geral do que há de novo e útil em termos de monitoramento e vigilância.



Em tese, o post deve ser do interesse de quem não é indiferente ao tema monitoramento e localização de problemas no PostgreSQL - administradores de sistemas, DBA, SRE, DBRE.



  1. Em pg_stat_activity adicionado um novo campo query_id. O campo contém o ID do pedido semelhante ao de pg_stat_statements . Assim, usando um trio de campos datid / userid / query_id, você pode anexar pg_stat_statements e visualizar as estatísticas acumuladas para um tipo específico de consulta. Uma nuance engraçada - os nomes dos campos para a fusão entre pg_stat_activity e pg_stat_statements são diferentes.



    Cuidado, texto
    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 agora também mostra o arquivador WAL na lista de processos. Até o momento, não há muitas informações, portanto, não são particularmente informativas e há espaço para desenvolvimento posterior.

  3. Em pg_stat_activity para processos wal sender (participando da replicação), o campo de consulta exibe o comando do protocolo de replicação. Essa pequena melhoria permite rastrear comandos de replicação entre mestre e réplicas, antes só era possível por meio de logs com o parâmetro log_replication_commands habilitado.

  4. O campo waitstart foi adicionado a pg_locks - o tempo a partir do qual a espera começou. O campo permite obter o tempo limite sem anexar pg_stat_activity. Por um lado, parece ser conveniente, mas para pegar o texto da consulta, você ainda precisa anexar pg_stat_activity. Mas para uso como métrica, é bastante adequado. neste caso, o texto da consulta pode não ser interessante.



    Parece que
    # 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_statementsgeneric_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
    
          
          









Isso é tudo.



Para concluir, gostaria de fazer um anúncio do evento - PG Day'21 Rússia acontecerá online nos dias 8 e 9 de julho . Será um hangout de fãs do PostgreSQL de dois dias com 12 palestras de palestrantes nacionais e estrangeiros. A participação é gratuita. A aceitação dos trabalhos também está aberta até o dia 7 de junho.



Só isso, obrigado pela atenção!



All Articles