pg_stat_statements是PG中监控数据库活动的重要插件,通过它可以获得SQL的统计信息,例如该SQL被调用了多少次,返回了多少记录,在读写数据上花了多少时间,这个对于监控数据库很有帮助。默认情况下,这个插件可以统计5000个SQL,如果不够可以调整pg_stat_statements.max这个GUC。
一般情况下,可以通过源码安装该插件:
1, 先编译安装pgsql
2,在pg源码的目录下执行 make install -C contrib/pg_stat_statements
3,修改pg的配置文件postgres.conf,在其中加上一行
4,启动数据库,执行下面的SQL添加该插件:
该语句会在当前的数据库中创建一个视图pg_stat_statements,这个视图中包含了很多有用的监控信息.简单的说来,这个插件会在PG数据库初始化的时候从共享内存中申请一块区域,这块区域主要是用作一个hash表,这个hash表将用来存储SQL的统计信息,默认是5000个不同的SQL。
前面说到这个插件默认统计5000个SQL,那么如果新执行了一个SQL,该插件则会以SQL的查询计划为输入来计算hash码,(这个hash码就是pg_stat_statements视图中的queryid),然后去插件的哈希表中查找,如果发现该hash码和某个已经存在的SQL的queryid相同,则将统计结果累加到这个SQL的统计结果中;没有发现,则会添加到插件的hash表中,或是满了5000条了就通过类似LRU的算法替换掉某个SQL(这点细节需要看代码)。
因此,这个插件在比对SQL时,智能程度还是很高的,只有语义上相同才会当作相同的SQL。例如下面三个SQL:
select * from t1 where a =2;
select * from t1 where a =3;
会被这个插件当作一个SQL(严格上说是一类)。
但是,有时候太智能也不太好:今天早上一个开发的同事来找我,说从pg_stat_statements中获得了很多重复的结果。登上他的测试环境,结果的确让人很奇怪:
很明显,结果中出现了三种重复的结果:一种是执行pg_xlog_location_diff函数的SQL;一种是执行drop操作;最后一种就是执行insert 操作。
第一眼看上去很吃惊,但是查看了文档http://www.postgresql.org/docs/9.4/static/pgstatstatements.html,再结合下SQL的处理流程,可以回答为什么前会有前两种重复的结果:
1,对于执行select pg_xlog_location_diff() 这样的SQL,主要是因为执行SQL的用户不一样,所以插件认为是不同的SQL。并且,如果同一个用户连接不同的数据库去执行同一个SQL,插件也会认为是不同的SQL。从查询计划的角度来看,用户不同或是连接的数据库不同,即使其他内容相同,在数据库看来,也是不同的查询计划了。
2,对于drop 操作的SQL重复出现,其实可以从文档里面就知道了,因为文档里面说的很明确了“Plannable queries (that is, SELECT, INSERT, UPDATE, and DELETE) are combined into a single pg_stat_statements entry whenever they have identical query structures according to an internal hash calculation.” 换言之,drop操作是没有查询计划的,因此没法判断一个drop操作之间是否相同,所以干脆当作都不同的
最后,对于insert 操作的SQL重复出现,刚开始怎么也无法解释,后来问了问开发的同学怎么操作数据库的,就恍然大悟了:因为他每次连数据库都会建立一个心跳表,这是个临时表,然后执行那一堆insert 操作来判断数据库是否活着。
一说临时表,就明白了七八分:因为他的临时表是session级别的,一个session连上来建立的临时表在断开session时,pg会自动删除临时表。虽然每次建立的临时表都是同一个表,一模一样,但是从数据库的角度来说,就是一个不同的表的了。所以每次session 第一次insert 这个表的SQL都会和前一次session执行的insert SQL是不同的,虽然他们字面上是一模一样的。当然,他们生成的查询计划的语义也是完全不一样的了。 而且考虑到pg_stat_statements的容量有限,最好还是建立一个非临时表。
相关推荐
复制到 pgsql-12/lib 目录下就...shared_preload_libraries = 'timescaledb, pg_stat_statements' # (change requires restart) pg_stat_statements.max = 10000 pg_stat_statements.track = all 最后重启postgrelSQL
pg_stat_plans:pg_stat_statements变体,用于区分查询计划。 版本:1.0 作者:Peter Geoghegan 基于Peter Geoghegan和Simon Riggs的想法。介绍pg_stat_plans是标准Postgres contrib模块pg_stat_statements的变体。 ...
它以pg_stat_activity间隔(默认为每秒)查询pg_stat_activity视图。 用法很简单: $ pgactivity通过设置libpq环境变量对其进行配置。 所有可能的值,。 通常,您需要设置PGHOST , PGUSER和PGPASSWORD : $ PGHOST...
pg_stat_monitor:PostgreSQL统计信息收集器
pg_stat_kcache:收集有关后端完成的物理磁盘访问和CPU消耗的统计信息
但是,在使用 CRS_STAT 命令时,可能会遇到各种错误,例如“crs_stat -t 报错1”。在本文中,我们将对 CRS_STAT 命令的错误进行分析,并提供解决方案。 错误原因分析 CRS_STAT 命令的错误可能是由于多种原因引起的...
设置受限的监控用户默认情况下,某些统计视图(例如pg_stat_statements和pg_stat_activity)不允许查看其他用户运行的查询,除非您是数据库超级用户。 由于您可能不希望监视以超级用户身份运行,因此可以这样设置一...
SAS_STAT_9.2_User's_Guide SAS_STAT_9.2_User's_Guide
STAT_VER’ undeclared 错误,如采用网上通用的直接宏定义_STAT_VER方法虽也可以编译通过,但最后生成的文件系统大概率为非root用户,系统随可启动,但是相关命令运行及proc文件系统挂在等都存在问题。 其他嵌入式...
为了解决这些问题,需要进行慢SQL分析,包括获取SQL语句、获取表相关信息、获取pg_stat_all_tables、pg_stat_all_indexes、pg_statio_all_tables、pg_statio_all_indexes等视图分析、收集慢SQL对应时间段的系统资源...
10gRAC系列之三-使用crs_stat工具查看资源状态[借鉴].pdf
概念该扩展基于PostgreSQL统计视图以及contrib扩展pg_stat_statements和pg_stat_kcache 。 它是用纯pl / pgsql编写的,不需要任何外部库或软件,但是PostgreSQL数据库本身和执行定期任务的类似cron的工具。 最初在...
ngx_http_stat_module ngx_http_stat_module 是 nginx HTTP 服务器的插件。 这是一个高性能的 nginx 模块,用于通过 UDP 将一些 http 请求记录到 stats 守护进程中。 stat 守护进程收集、累积和处理统计信息。 该...
hpftp_glob_stat
dm_hs_cy_stat.sql
_mingw_stat64.h
nbt_stat.h
net_stat.h
rn_stat.R
此扩展要求安装pg_stat_statements,以便唯一标识标准化的查询。 使用查询标识符不足以唯一地标识一条语句。 根据查询中仍然存在的常量为每个条目计算一个附加的constid哈希。 此外,如果查询依赖于启用行级安全性...