PostgreSQL 玩PG我们是认真的，vacuum 稳定性平台我们有了

对于这一个问题不清楚的同学可以参考下面的连接，我们为什么要研发 vacuum 稳定性平台，以及我的系统设计和一些界面等。

公布我们开始研发vacuum稳定性平台的初衷和工作进度

接着上次的我在PG大会上提到的我们自研的系统，目前已经正式在生产系统上部署了，目前1个多月运行的情况是良好的，当然应用系统的都是大库4T以上，部分大表在500G以上，这次我们就来说说我们运行的情况以及我们在系统中做的改进。

系统原有的功能；

1 自动分析当前数据库中，用户表的情况并且针对分析后的数据将表至少分为3类，并且将表打入队列根据2中算法，来将这些表进行前后优先级排序后，进行表的整理，并且指定整理的时间和整理后的日志。

2 可以手动的来对表进行相关的手动的vacuum的操作，当然手动操作必须是通过分析进入到执行列表的表。

3 给每个表展示表状态的信息的窗口，比如表多长时间做了 autovacuum，vacuum ，analyze 等信息，并且动态展示表的 dead tuples 与live tuples的比率等等。

4 操作后，会记录日志，会将一些的详细信息进行记录，以供相关的人员查看。

一开始功能是粗糙的，但经过使用，我们得到了内部客户的一些反馈并且我们也意识到一些新的功能对于实际的POSTGRESQL 运行时有用的。

1 用户提出，对于一些系统中运行中突然增加的特殊表处理后，导致的执行计划问题，希望能有手动的analyze 的按钮来对表进行手动的analyze操作。 的确这是一个问题，之前我们的确在这个方面都是开发通知DBA 来进行操作，DBA 对于这个工作是叫苦不堪，因为工作量不大但很是烦人。

有这个系统有，开发可以进入到系统里面对于要操作的表进行操作，当然他们只能进行analyze 的操作，手动的。

2 在开发介入到这个系统后，就涉及了权限的部分，目前系统单独开发出两个权限，最高级的权限，和普通权限，普通的权限是只能看和对表进行analyze 的操作，而高级权限是什么都可以做。

3 参数的调节，对于我们之前文章中提出的一些需求，需要对于表级别停止 autovacuum的操作，这个我们在版本2中做了改进，我们的新的版本的（测试）已经开始支持，部分表参数的调节，通过调节来满足相关的业务需求，比如调整autovacuum 的 enabled, insert_scale_factor, vacuum_threshold 等，参数并且支持这些参数，在修改后在重新设置成 default值等，还针对这些参数的特点，设置了上限和下限，放置不熟悉的DBA 在使用中乱写，导致系统问题。

4 针对一些特殊的紧急的情况，第二期版本中已经允许DBA 在界面上对于没有进入日常维护工作列表的表，进行手动的vacuum操作。

（图中在测试版本中，添加的分析，参数调整，和手动vacuum的按钮和相关的任务）

同时为了保证vacuum 和 analyze 的执行中不产生冲突，我们产生了两个流水线来进行 vacuum 和 analyze的操作独立，并且独立展示执行后的结果的查询。

同时我们也重新设计了数据库的页面，支持了表参数的调节，尤其是关闭autovacuum的参数，那么必然我们要给客户进行相关的信息的展示，放置，我们这里将页面设置在每个数据库的头部页面上，方便进行改动后的表的展示，也方便集中化管理。

在运行这个系统的一个月里面，我们已经和不运行这个系统的数据库进行了一些运行状态的比对。

1 系统在业务高峰期触发autovacuum的次数，在运行了这个系统后，基本为0 ，也就是说POSTGRESQL 在业务高峰期已经达不到触发autovacuum的状态了，基本上这个系统每天就将需要autovacuum的工作都在业务的非繁忙时间做完了。

2 系统提供了大量的vacuum工作的界面化操作，降低了DBA 的工作强度，提高了工作效率。

3 一个月来看，运行了这个系统的数据库，添加磁盘空间的频率变慢了，相对于那些没有使用这个系统的同业务系统。

当然基于我们有比较大的众多的POSTGRESQL 数据库，所以我们在实践环境和持续发现需求的方面是有很多储备的，我们会随着我们的使用和逐步发现问题，持续更新系统，可能会考虑在完善的时候进行一个开源。