1.1 数据库统计信息
1.1.1 概述
l 统计信息主要记录的就是表的行数页面以及不同列不同值的分布关系。
l 表和索引的行数、页面数记录在系统表pg_class中，不同列不同值的分布关系在pg_statistic中。
l PgStat子进程是专门的统计信息收集器进程。
l ANALYZE命令可以收集的统计信息，ANALYZE命令可以作为VACUUM的一个可选步骤。
l 可以由autovacuum后台进程触发一次统计信息的更新操作。
l 可以手工通过ANALYZE命令收集统计信息在某个表上，甚至某个列上。
l 最好规划一个数据库范围内的ANALYZE，然后每天在系统不太繁忙的时候运行一次。
1.1.2 自动收集
自动收集统计信息是依赖AUTOVACUUM定时触发analyze：
触发 vacuum analyze的条件,表上(insert,update,delte 记录) >=
autovacuum_analyze_scale_factor* reltuples(表上记录数) + autovacuum_analyze_threshold
1.1.3 手动收集
手动收集统计信息的命令是analyze命令，analyze的语法格式：
analyze [verbose] [table[(column[,..])]]
verbose：显示处理的进度，以及表的一些统计信息
table：要分析的表名，如果不指定，则对整个数据库中的所有表作分析
column：要分析的特定字段的名字默认是分析所有字段
analyze 命令 会在表上加读锁
1.1.4 收集过程
统计信息记录在哪里
用于进行查询计划选择的统计信息记录在系统表内
pg_statistic 记录值的分布率
pg_class 记录行数和页面数
http://postgres.cn/docs/12/catalog-pg-class.html
谁来更新统计信息
统计信息是有autovacuum进程更新，PG使用MVCC机制进行数据库的并发控制，因此同样需要一组后台进程进行过期版本的清理。
autovacuum进程不止负责对过期元组进行清理，同时也负责定期更新表的统计信息。
为什么要把这两个操作放在一起？
PG的MVCC机制数据和数据的旧版本是统一存放在表文件上的，在清理时要进行全表扫描的操作，而统计信息的收集也是需要读取表文件的，这两个操作放在一起做可以在一定程度上节省IO；
清理废旧元组和更新统计信息都是通过收集表的元组变更数据来触发的，共享一套机制，因此放在一起处理也比较方便；
何时触发统计信息（when）
统计信息有两种触发方式：
用户使用analyze命令手动触发(analyze/vacuum analyze)
在PG中，事务提交/回滚时会发消息给进程pgstat，pgstat会汇总这份信息并记录到文件中，autovacuum launcher会定期读取文件，获得，当某个表的改动超过阈值时便会触发一次统计信息的更新操作。
需要注意的是autovacuum worker也会给pgstat发消息，但实际上这个消息是通知pgstat统计更新/清理已经完成，可以清理统计信息了。因此stat file只有pgstat更新，launcher只是读取，不涉及并发写冲突。
1.1.5 收集进程及目录存放
PG用于收集统计信息的进程
stats collector process 源码路径 ："src/backend/postmaster/pgstat.c"
统计信息的存放地启动时, 读入已存在的统计文件, 或初始化0. 数据库运行过程中存储在内存和temp文件 postgresql.conf ->stats_temp_directory , 推荐配置在高速磁盘或内存文件系统中
,正常关闭时会把统计信息从tmp目录拷贝到$PGDATA/pg_stat目录中，确保统计信息不会丢失。
1.1.6 收集维度配置
以pg_stat开头的统计表和试图是否产生统计数据，主要由以下参数决定：
track_activities：是否收集当前正在执行的SQL，默认为on
track_counts：是否收集表和索引上的统计信息，默认为on
track_functions：可以取all、pl和none，如果是pl则只收集pl/pgsql写的函数的统计信息；
all表示收集所有类型的函数，包括C语言和SQL写的函数。默认为none
track_io_timing：是否收集I/O的时间信息。一般不建议打开，默认为off
1.1.7 收集维度配置
1.1.8 查看与重置函数
1.1.9 查看与重置函数
查看会话 | 服务端进程级别统计信息的函数, 根据进程ID查询统计信息。
1.1.10 统计信息视图
查看统计信息的视图（查看）
pg_stat和pg_statio开头的系统视图
重要的信息的视图
pg_stat_activity（实时）
pg_stat_database（累积）
pg_stat_all_tables（累积）
pg_stat_all_indexes（累积）
1.1.11 表及视图
各个对象级别的统计信息视图：
pg_stat_database
pg_stat_all_tables
pg_stat_sys_tables
pg_stat_user_tables
pg_stat_all_indexes
pg_stat_sys_indexes
pg_stat_user_indexes
数据库内函数的调用次数及其他信息进行统计的视图
pg_stat_user_functions
备注：这些数据的第一个用途就是监控数据库上vacuum（清理）工作的执行效果；
譬如，你可以获得在上一次vacuum或者autovacuum执行后的活跃元组和死亡元组的数量以及时间戳。
1.1.12 表及试图
各个对象上发生I/O情况的统计视图：
pg_statio_all_tables
pg_statio_sys_tables
pg_statio_user_tables
pg_statio_all_indexes
pg_statio_sys_indexes
pg_statio_user_indexes
pg_statio_all_sequences
pg_statio_sys_sequences
pg_statio_user_sequences
1.1.13 pg_stat_statements模块
l 追踪数据库执行的所有 SQL 语句的执行统计信息，统计数据库的资源开销，分析TOP SQL。
l 在postgresql.conf的shared_preload_libraries中增加pg_stat_statements来载入。
l 需要额外的共享内存。
l 增加或移除该模块需要一次服务器重启。
l 视图 pg_stat_statements以及函数pg_stat_statements_reset 用于访问和操纵这些统计信息。
l 这些视图 和函数不是全局可用的。
l 可以用CREATE EXTENSION pg_stat_statements 为特定数据库启用它们。
1.1.13.1 实验案例
pg_stat_statements.max = 1000000
# 在pg_stat_statements中最多保留多少条统计信息，通过LRU算法，覆盖老的记录。
pg_stat_statements.track = all
# all - (所有SQL包括函数内嵌套的SQL), top - 直接执行的SQL(函数内的sql不被跟踪), none - (不跟踪)
pg_stat_statements.track_utility = off
# 是否跟踪非DML语句 (例如DDL，DCL)，on表示跟踪, off表示不跟踪
pg_stat_statements.save = on
# 重启后是否保留统计信息
shared_preload_libraries='pg_stat_statements'
track_io_timing = on #如果要跟踪IO消耗的时间，需要打开如上参数
track_activity_query_size = 2048 #设置单条SQL的最长长度，超过被截断显示（可选）
create extension pg_stat_statements;
select * from pg_stat_statements;
shared_preload_libraries='pg_stat_statements'
#加载pg_stat_statements模块
track_io_timing = on
#如果要跟踪IO消耗的时间，需要打开如上参数
track_activity_query_size = 2048
#设置单条SQL的最长长度，超过被截断显示（可选）
#以下配置pg_stat_statements采样参数
pg_stat_statements.max = 10000
# 在pg_stat_statements中最多保留多少条统计信息，通过LRU算法，覆盖老的记录。
pg_stat_statements.track = all
# all - (所有SQL包括函数内嵌套的SQL), top - 直接执行的SQL(函数内的sql不被跟踪), none - (不跟踪)
pg_stat_statements.track_utility = off
# 是否跟踪非DML语句 (例如DDL，DCL)，on表示跟踪, off表示不跟踪
pg_stat_statements.save = on
# 重启后是否保留统计信息
1.1.13.2 常用的统计sql参考
最耗IO SQL，单次调用最耗IO SQL TOP 5
select userid::regrole, dbid, query from pg_stat_statements order by (blk_read_time+blk_write_time)/calls desc limit 5;
总最耗IO SQL TOP 5
select userid::regrole, dbid, query from pg_stat_statements order by (blk_read_time+blk_write_time) desc limit 5;
最耗时 SQL，单次调用最耗时 SQL TOP 5
select userid::regrole, dbid, query from pg_stat_statements order by mean_time desc limit 5;
总最耗时 SQL TOP 5
select userid::regrole, dbid, query from pg_stat_statements order by total_time desc limit 5;
响应时间抖动最严重 SQL
select userid::regrole, dbid, query from pg_stat_statements order by stddev_time desc limit 5;
最耗共享内存 SQL
select userid::regrole, dbid, query from pg_stat_statements order by (shared_blks_hit+shared_blks_dirtied) desc limit 5;
最耗临时空间 SQL
select userid::regrole, dbid, query from pg_stat_statements order by temp_blks_written desc limit
1.2 OS资源使用统计信息
1.2.1 系统的负载
cpu资源
内存资源
磁盘I/O
网络I/O
详细请参阅文档《Linux性能监控 - CPU、Memory、IO、Network》
nmon系统资源监控工具
iostat vmstat sar free top
1.3 常用监控工具概述
1.3.1 PG常用监控工具
1.3.1.1 PoWA
PoWA 全称是 PostgreSQL Workload Analyzer ，是用来分析 PostgreSQL 数据库负载的工具。提供统计数据收集、实时图表和性能分析。
https://github.com/powa-team/powa
1.3.1.2 pgwatch
https://pgwatch.com/
1.3.1.3 pgmetrics
pgmetrics是一个开源,零依赖的二进制工具，用于收集和报告运行中的PostgreSQL服务器上的各种统计数据和信息，以帮助故障排除、监控以及自动化。并可以以文本格式显示，或者以JSON和CSV格式导出。
安装极其简单：不需要任何第三方插件依赖，解压即可使用
https://pgmetrics.io/docs/
1.3.1.4 zabbix
a.libzbxpgsql
b.pg_monz
c.prometheus
https://www.cnblogs.com/ilifeilong/p/10543876.html
1.3.1.5 pigsty
http://pigsty.cc/zh/docs/overview/
1.3.2 pgmetrics实验
建议
1、设置语句超时时间，为业务可接受时间。（因为每个指标都要调用对应的SQL来进行采集，万一因为锁堵塞导致采集不及时，可以避免长时间等待）。
例子
1、超时时间为3秒，不输入密码，不分页，输出JSON格式，输出到文件，采集实例信息、系统信息、数据库postgres与newdb信息。
pgmetrics -t 3 --no-password --no-pager -f json -o ./log_`date +%s` postgres 数据库名
2、同上，只是输出的为TEXT格式。
pgmetrics -t 3 --no-password --no-pager -f human postgres newdb
3、使用已保留的JSON文件，生成text报告.
pgmetrics -i ./log_1538406857 --no-pager|less
4.
./pgmetrics -h localhost -U postgres -t 3 --no-password --no-pager -f human -o pgmetrics_out2.txt postgres
