2

我们正在为我们的生产评估 PostgreSQL 11.1。拥有一个每秒更新 4251 次、每秒删除约 1000 次、每秒插入约 3221 次、每天处理 10 亿次事务的系统，我们面临的挑战是 PostgreSQL 不重用其（删除/更新）空间，并且表的大小不断增加.

我们配置了激进的 Autovacuum 设置以避免环绕情况。还尝试添加定期执行vacuum analyze和vacuum- 仍然没有空间重用。（仅vacuum full或pg_repack向操作系统释放空间——但这不是重用。）

以下是我们的真空设置：

autovacuum                          | on
vacuum_cost_limit                   | 6000
autovacuum_analyze_threshold        | 50
autovacuum_vacuum_threshold         | 50
autovacuum_vacuum_cost_delay        | 5
autovacuum_max_workers              | 32
autovacuum_freeze_max_age           | 2000000
autovacuum_multixact_freeze_max_age | 2000000
vacuum_freeze_table_age             | 20000
vacuum_multixact_freeze_table_age   | 20000
vacuum_cost_page_dirty              | 20
vacuum_freeze_min_age               | 10000
vacuum_multixact_freeze_min_age     | 10000
log_autovacuum_min_duration         | 1000
autovacuum_naptime                  | 10
autovacuum_analyze_scale_factor     | 0
autovacuum_vacuum_scale_factor      | 0
vacuum_cleanup_index_scale_factor   | 0
vacuum_cost_delay                   | 0
vacuum_defer_cleanup_age            | 0
autovacuum_vacuum_cost_limit        | -1
autovacuum_work_mem                 | -1
4

1 回答 1

2

您的要求对于 PostgreSQL 来说尤其困难。

  • 您应该autovacuum_vacuum_cost_delay为该表设置为 0。

  • 重置autovacuum_max_workers并autovacuum_naptime返回其默认值。

  • autovacuum_vacuum_scale_factor将和重置autovacuum_analyze_scale_factor为其默认值或稍低的值。

您的问题不在于 autovacuum 运行不够频繁，而在于它太慢而无法跟上。

即使这样，您也可能只能通过 HOT 更新来处理此工作负载：

  • 确保经常更新的属性不属于任何索引。

  • 创建一个fillfactor低于 100 的表，比如 70。

HOT 更新通常避免了VACUUM更新索引的需要和需要。

检查n_tup_hot_upd列pg_stat_us-er_tables以查看它是否有效。

于 2019-03-04T11:29:55.470 回答