本节介绍了PostgreSQL中与AUTOVACUUM相关的参数：autovacuum_max_workers 。 ### 概览 PG的MVCC要求“过期”的数据不能马上被物理清除，而是标记为dead rows，这些dead rows后续会通过vacuuming过程清理。 vacuuming通过以下方式让数据库保持“健康”： 1.标记dead rows可用于存储新数据，这样可以避免不必要的磁盘浪费以及可以跳过dead rows以提升顺序扫描的性能； 2.更新vm（用于跟踪过期或已废弃的数据，反应在pages上）。这可以提升index-only scans的性能； 3.避免出现事务ID回卷而导致的数据库宕机。 PG提供了autovacuum机制，通过周期性的运行ANALYZE来收集最近频繁更新的数据表统计信息，基于这些统计信息autovacuum进行调度清理dead rows。 ### Worker个数 PG提供了配置参数autovacuum_max_workers用于配置autovacuum worker的个数，从直观的感觉来看，提升该参数意味着有更多的worker进程，可以有效的提升autovacuum的吞吐，但实际上由于autovacuum_vacuum_cost_limit参数的限制，单纯的提升autovacuum_max_workers并没有什么效果。 由于autovacuum_vacuum_cost_limit对成本的限制是全局的，也就是说该参数控制了全局的worker可达到的成本上限，就算提高了autovacuum_vacuum_cost_limit，吞吐量也不会有提升。打个比方，启用多线程往文件系统中写文件，但总的吞吐限制为10MB/s，每个线程的吞吐最多只能是(10MB/线程数)/s也就意味着不管你启用多少个线程，最高的吞吐也只能是10MB/s，除了增加线程数（autovacuum_max_workers）还需要增加总的吞吐限制（autovacuum_vacuum_cost_limit）。 ### 个性化解决方案 PG提供了面向单个表的个性化autovacuum解决方案，可以在表级上设置autovacuum_vacuum_cost_limit、autovacuum_vacuum_cost_delay等参数。表上的autovacuum_vacuum_cost_limit参数不纳入到全局的统计数字中。 ``` [local:/data/run/pg12]:5120 pg12@testdb=# create table t(id int); CREATE TABLE [local:/data/run/pg12]:5120 pg12@testdb=# ALTER TABLE t SET (autovacuum_vacuum_cost_limit = 1000); ALTER TABLE [local:/data/run/pg12]:5120 pg12@testdb=# ALTER TABLE t SET (autovacuum_vacuum_cost_delay = 10); ALTER TABLE [local:/data/run/pg12]:5120 pg12@testdb=# ``` ### 参考资料 [Monitoring PostgreSQL VACUUM processes](https://www.datadoghq.com/blog/postgresql-vacuum-monitoring/) [Postgres Autovacuum is Not the Enemy](https://www.citusdata.com/blog/2016/11/04/autovacuum-not-the-enemy/) [Tuning Autovacuum in PostgreSQL and Autovacuum Internals](https://www.percona.com/blog/2018/08/10/tuning-autovacuum-in-postgresql-and-autovacuum-internals/) [Autovacuum Tuning Basics](https://www.2ndquadrant.com/en/blog/autovacuum-tuning-basics/)