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

如上篇文章提到，若是出现了autovacuum的问题，那么这多是个悲伤的故事。怎么解决？

笔者以为能够从以下几个方面着手去考虑解决问题，能够避免一些坑。
        1)持续观察，是否是autovacuum问题一直存在，若是只是偶尔出现一次，可能不须要那么慌张。由于颇有多是其余异常状况形成的。好比当时正在作大规模数据迁移等操做，这种操做若是是偶发的，大可没必要在乎。

2) 笔者通常的分析思路是从大到小，好比先检查外围的关键配置项，若是有必要的话，再去深究postgres autovacuum相关的配置项。由于整体来讲，调优和分析问题时要切记舍本逐末。就这个问题而言，咱们知道数据库的读写操做，能够先分开看，这样比较容易理解。读，是从disk读取到OS(操做系统，如Windows/Linux等) cache,再抓取到postgres cache(buffer)，是这样一个过程。而写的操做相反，从postgres cache 先写到os cache，再最后写入disk。因此说了那么多，是想表达，外围的设置很是关键，postgres服务器也应该预留足够的资源给操做系统（如内存，最好能达到20%，甚至更多一点），若是忽略了大的方面的配置检查和做业，极可能会使调优工做走向不归路。

3)如上篇文章提到的，autovacuum相关的配置，有大体12个之多，可是真正在开始调整这些参数时要注意的是，有些参数从个人经验来看，最好先不要动，好比“autovacumm_max_workers”;其默认值为3，当某些表dead tuple增多时，特别是占用了50%以上tuples的时候，能够先调小参数“autovacuum_vacuum_scale_factor”的值。好比能够从默认的0.2调整为0.1，增长vacuum的频率，可能就能解决问题。autovacumm_max_workers最好先不动，是由于若是动了它，可能会有一些反作用，得不偿失，具体会在第4点说明。以前笔者在项目中就遇到了这样的坑。

4)若是此时vacuum的问题解决以后，发现有些SQL执行仍是很慢，经过监控可能发现SQL执行时间起伏比较大。那么咱们要知道一点的是，autovacuum过程不仅作了vacuum的动做，其实还作了另一个动做，那就是“Analyze"，通俗来讲，这个动做就是为了完成在tuples更新（磁盘更新）以后，执行计划也应该相应更新，以求获得最佳/最优执行计划等等，也很关键。你们能够经过调整“autovacuum_analyze_scale_factor”或参数“autovacuum_analyze_threshold”,若是对于表记录过多，如超过10000行，能够直接考虑调整前一个参数便可。

Autovacuum的问题调优，到这里告一段落。若是有其余问题或者项目中遇到奇怪的和autovacuum相关的问题，欢迎留言。

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