理論的には、この投稿は、PostgreSQLの問題の監視と発見のトピックに無関心ではない人（システム管理者、DBA、SRE、DBRE）にとって興味深いはずです。
- でをpg_stat_activity新しいフィールドQUERY_IDを追加しました。このフィールドには、pg_stat_statementsと同様のリクエストIDが含まれています。したがって、datid / userid / query_idフィールドのトリオを使用して、pg_stat_statementsを添付し、特定のタイプのクエリの累積統計を表示できます。面白いニュアンス-pg_stat_activityとpg_stat_statementsの間のマージのフィールドの名前が異なります。
注意、テキスト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
- Pg_stat_activityは、プロセスリストにWALアーカイバも表示するようになりました。これまでのところ、情報はあまりないので、特に有益ではなく、さらなる発展の余地があります。
- wal送信者プロセス（レプリケーションに参加している）のpg_stat_activityで、クエリフィールドにレプリケーションプロトコルコマンドが表示されます。この小さな改善により、マスターとレプリカ間のレプリケーションコマンドの追跡が可能になります。以前は、log_replication_commandsパラメーターが有効になっているログを介してのみ可能でした。
- waitstartの待ち時間が始まったから、時間-フィールドは、としてpg_locksに追加されました。このフィールドでは、pg_stat_activityをアタッチせずにタイムアウトを取得できます。一方では便利なようですが、クエリテキストを取得するには、pg_stat_activityを添付する必要があります。ただし、メトリックとして使用するには、非常に適しています。この場合、クエリテキストは面白くない可能性があります。
そのように見えます# 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
- pg_stat_database. session_time, active_time, idle_in_transaction_time — , . — ( state), , () . — sessions, sessions_abandoned, sessions_fatal, sessions_killed . .
- 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
- 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
- — pg_stat_replication_slots. (PUBLICATIONS/SUBSCRIPTIONS, Debezium), pg_replication_slots.
- toplevel pg_stat_statements. pg_stat_statements , . , — . - , . .
- pg_stat_statements_info. — pg_stat_statements. , pg_stat_statements , . pg_stat_statements.max.
- pg_backend_memory_contexts — . . .
- , .
pg_log_backend_memory_contexts() — , , pg_backend_memory_contexts.
, — ( ) , , . . ( , ). , . , .
- pg_prepared_statements — generic_plans, custom_plans — . , .
- pg_get_wal_replay_pause_state(). pg_is_wal_replay_paused(). . — not paused, pause requested, paused.
- log_recovery_conflict_waits — WAL . , -.
- 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
- - 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
それで全部です。
結論として、私はイベントの発表をしたいと思います-PG Day'21ロシアは7月8日と9日にオンラインで開催されます 。これは、国内外のスピーカーから12回の講演が行われる2日間のPostgreSQLファンのたまり場になります。参加は無料です。論文の受け入れでもある オープン6月7日まで
すべてです、ご清聴ありがとうございました！