postgreSQL之autovacuum性能问题分析(一)

最近笔者在项目中遇到postgreSQL的性能问题，因此计划在公众号里写一个系列文章去追踪记录这些问题以及分析过程或解决方法。

本文主要是关于postgreSQL的autovacuum的问题。可能不少人对postgreSQL中的autovacuum是干什么的不是特别清楚。网上其实对其概念有了不少的描述。我本身的理解就是，数据库经过必定的逻辑判断对数据库的一些存储资源进行自动地回收再利用的行为就是autovacuum.

自从postgreSQL8.1版本引入这个功能以后，不少状况下在使用时，是开启autovacuum的，我也特别赞同开启这个功能。由于人工去作vacuum操做，很差判断时机和频率：若是vacuum不及时，不足够频繁会形成dead tuples数据过多，形成表相关update/deletion操做性能降低；若是过于频繁会形成cpu和磁盘读写的繁忙，一样会形成性能问题。

那么autovacuum会不会有性能问题呢？答案是：可能。autovacuum是把vacuum的操做的频率和时机交给数据库去断定，按理说，这应该是理想状态或者最优解了，其实未必。在系统上线时若是针对自身业务，未对autovacuum参数进行调优，使用默认值时极可能是有问题的。那么怎么找到相关配置呢？

两种方式查看postgreSQL相关的配置。

*     postgreSQL安装目录下，找到配置文件postgresql.conf

*     能够经过以下SQL语句在postgresql中直接查看autovacuum相关的配置

select * from pg_settings where name like 'autovacuum%';

通常默认的操做值以下，这里面主要包括2部分，一部分是vacuum，另一部分是analyze. Analyze也是很是重要的built-in操做，会在后续的文章中详细介绍。这里主要讲解下经常使用的，比较重要的几个参数，其中“autovacuum_max_workers”,定义了最大的autovacuum的进程数，默认是3. 也就是说同时能够操做3个表的vacuum操做; "autovacuum_vacuum_threshold"是针对一些小体量的表而言，若是有一张表常年的体量就是20条数据左右，那么这张表可能永远不会被autovacuum考虑在内，由于参数autovacuum_vacuum_threshold设定的默认值为50(>20); "autovacuum_vacuum_scale_factor",这个参数，会考虑的比较多，针对一些大致量的表，好比有1亿行数据，那么针对参数值为0.2的时候，若是dead tuples达到2千万行时，会说明此时须要autovacuum，若是vacuum workers的线程被占满，那么就会排队。

       那么怎么去断定某个特定的表是否有autovacuum的问题呢？那么笔者的经验是首先须要一个多时间节点的观察。若是都知足以下条件，说明相关表是时候进行清理dead_tuples了。

pg_stat_all_tables.n_dead_tup > (threshold + pg_class.reltuples * scale_factor)

       在以上的表达式中，其中能够经过表pg_stat_all_tables的n_dead_tup字段,加上relname的条件（即表名），就能够获取到特定表的dead tuples的数值；threshold便是postgreSQL中的"autovacuum_vacuum_threshold"参数的值，默认为 50. pg_class.reltuples能够附加查询条件 relname="表名"查询到表中总tuple数; scale_factor是postgreSQL中的"autovacuum_vacuum_scale_factor"参数的值，默认为0.2。若是以上不等式成立，那么说明当前表是须要清理dead tuples的，此时能够监控postgreSQL当前正在进行的autovacuum是否是有包含当前表，若是没有，那么可能就须要对autovacuum进程进行调优了。其次是若是有，可是若是dead tuples一直占有很大比例，那么也须要进行关注性能问题。

      下次会讲解当遇到了autovacuum的问题，怎么去解决，须要注意什么。敬请期待。

      你们也能够扫描并关注以下公众号“TimTest”，会有更多性能测试相关内容分享。