【转】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】,原文地址：https://mp.weixin.qq.com/s?__biz=MzI2OTYwMDc0MQ==&mid=2247483655&idx=1&sn=4c1ad5eebd2cec8d5436168f762b127b&chksm=eadc938dddab1a9b9ca800114de0779c44cb1ab738570f20fc78e46a66c51e097ea34d59b82e&token=2021082705&lang=zh_CN#rd