Postgresql 表bloating 怎么办 ---pg_bloat_check 你造(知道)吗?

2021-08-04 00:00:00 都是 安装 监控 建立 空间


基于PG 的原理表膨胀的问题估计现在就算是PG的边缘人士都知道了,这实际上也不是什么缺点, 只是集中和分散的设计理念的不同而已. 但监控表的bloating 那倒是一项必须的工作. 在PG内部通过SQL语句脚本来查看表的bloating 是一种方法. 今天要说的不是这样的方法,而是一个来查看PG表的bloating的工具  pg_bloating_check


还是按照老习惯, 先操作在理论,  pg_bloating_check 是需要一些前期的铺垫和支持的, 首先需要在PG的数据库中打入 pgstattuple 的extension


然后是安装,安装需要注意几点


1   python 脚本需要 python2.7 的版本支持

2   需要自行安装 pip 2.7

3   安装需要 pgcopg2 2.7 的版本,否则程序不能正常运行

4   为简单命令的执行,需要一个本地的账号并且是免密的账号,具体如何免密请自行查询方法


命令运行需要注意几点


1   在需要监控的数据库上建立统计表, 还是建立一个新的schema 来建立新的监控表. 

./pg_bloat_check.py -c "host=192.168.198.101 user=admin dbname=dvdrental"  --create_stats_table --bloat_schema=monitoring


这里在监控时是必须要建立表的,表的功能是承载每次获取的数据,方便后期的查询和数据的变更.  --bloat_schema 主要的目的是在要监控的数据库中schema 中建立统计信息表, 这里需要自行建立 schema , 否则会报错.



先看三个常用的选项

[p]   意思是 小浪费百分比, 这里的意思是空间未回收的情况与整体表占用空间的百分比的情况. 


[z]   意思是小的浪费的空间,如果不给单位则按照byte来计算,支持 mb, kb,tb 等单位


[s]   意思是多大的表需要进行扫描和记录,对于小表是否有必要进行扫描,相关单位也是和上面一样, mb, kb, tb 


这三个选项是整个程序对于使用者来说非常重要的,这里需要根据具体的情况来进行分析. 例如如果你的系统整体都是大表,都是1G 以上的表,那么对于小表可能你就不会太关心,所以对于 s 可以进行设置,小于1G 的表根本不在统计范围,  浪费空间也是一个维度,如果你在意你的表浪费的空间在10%以上就要被记录和显示,那就需要调整这个参数.


程序在执行后,会显示出如上图的信息,toast  index ,table 的信息,以及多少空间在wasted的状态.


那么我们回来在看看这个程序到底做什么什么


1  建立了统计的表,格式如下,记录了这个数据库中的表的大小,tuple的信息,,以及一些计算后的半分比.


系统本身会在当前使用的数据库加你了三个表 bloat_stats,  bloat_tables, bloat_indexes




后从SQL 的层次是可以分析并展示这些数据的,那么这个软件存在的意义,主要是定期在晚上来进行运行并将结果打印, 这样对于一些HOT的系统, 可以分析出一段时期的表膨胀的状态. 


注明: python 安装的问题不在讨论的范围内,需要百度自行解决.


https://github.com/keithf4/pg_bloat_check



相关文章