本節介紹了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/)

PostgreSQL DBA(145) - pgAdmin（AUTOVACUUM：引數解析#3）

相關文章