的确是，最近一直在研究和写autovacuum的事情，但造化弄人，阴沟翻船的事情也是不少预见了，这次就遇到了。（让你前5篇嘚瑟）

先简化的说一下事情，因为要调整参数，找到怎么快速激发autovacuum工作的方法，在参数的调试中，掉入了黑洞。

1 环境：PG  11.7   CPU 2 core   内存  16G   磁盘普通SATA

2  参数配置  SB 4G  autovacuum_mem 1G  maintanence_work_mem 1G

3  通过pgbench 灌入大表数据

对数据库产生数据压力，80客户端 每个客户端10个进程  不间断的进行DML操作

通过系统表可以看到，这里的测试表的小表的 autovacuum 很快就进行清理了。

下面系统表展示了表的活的tuple ， 死的tuple 以及 死的tuple 占整体的总行的百分比。最后面是autovacuum 最后一次的时间。

下图可以看到只有1 亿的大表的 autovacuum last 的时间没有动，和其他表相比，上一次autovacuum 的时间在 7 个小时前。 

基本上每秒死行在这个表上增加 200行左右。

根据前几篇写的，有的同学可能会提到，调整的参数  

autovacuum_vacuum_threshold   和  autovacuum_vacuum_scale_factor 这两个参数，可以看到已经调整过了，实际上针对大表应该单独进行调整，这里就偷懒了。具体如何进行单表调整，看第三篇即可。

但是调整成这样系统大表 pgbench_accounts 还是没有进行 autovacuum

随即苦恼了一天，继续测试找问题，

此时估计有同学会提出，三个应该 autovacuum 的工作的原因

1   长事务影响，导致 autovacuum 不能进行工作

2   有复制槽影响，并且复制停止了，导致autovacuum 不能工作

3   因为autovacuum 的cost 过大导致不能进行 autovacuum的工作

这里可以排除以上三个原因，这边没有长事务，单机，并且相关的 cost 已经调整（具体 cost调整 看第四篇）

所以autovacuum 不工作，或者无法更好的工作的原因还有其他的，并且网上我没有找到描述这方面的原因。

原因  1    autovacuum  对大表操作时间过长，通过观察系统中的活动的进程，可以发现实际上autovacuum 在工作中，只是工作的时间较长。

其他的表本身在进行autovacuum 很快就完成了工作。

所以第一个原因并不是autovacuum没有工作，而是工作的时间太长。

从另一个角度可以证明，对于大表的参数应该是单独调整，不应该在整体的参数进行配置， 对于大表的autovacuum 应该控制频度。频度太低和太高都对大表的vacuum操作无益处。

原因2  众所周知，在autovacuum 操作中，会带有两个操作 1 vacuum  2  analyze,  在autovacuum 操作完毕后，需要进行 analyze 的操作， 而大表的vacuum analyze 也不是很快的，所以有些时间 autovacuum 不操作的原因也有 analyze的因素，长时间无法完成 analyze ,自然会影响 autovacuum的 真空操作。

所以以上两个原因都是针对大表的很长时间没有进行autovacuum操作的奇葩原因。

遇到上面的问题主要要考虑

1   是否需要对表进行分区处理，单表无法进行并发的autovacuum 的操作，将表分区可以提高针对表的vacuum 的速度

2  存储大表的数据磁盘，替换为SSD 磁盘

3  通过降低autovacuum_analyze_scale_factor 参数的，减少对大表的 analyze时时间过长，阻碍 autovacuum vacuum 。

4  定期晚上进行手动的 vacuum 对于大表 ，在手动vacuum 时会autovacuum针对这个表的操作会停止。