我们在Azure云中使用postgres 11作为临时存储。在我们的批处理过程中，两个表在大量的小事务中接收大量的插入和删除（数亿），这些事务具有严重的锁争用。当所有数据都被处理完后，这些表最终将为空。由于通过这两个表的通信量很大，我们已经将autovacuum调优为对它们进行攻击autovacuum_vacuum_cost_limit=2000, autovacuum_vacuum_cost_delay=1, autovacuum_vacuum_scale_factor=0.02, autovacuum_vacuum_threshold=10000
自动真空通常跟上负载，并保持表的大小下降。我们有时也会在加载之间截断或运行vacuum full。但偶尔我们会注意到自动真空过程完全停止运行。大约在同一时间，我们开始在日志中看到xid环绕警告。当这种情况发生时，某些pg_catalog表的relfrozenxid年龄超过2亿，但我们正在使用的表却没有。
即使我们让数据库处于安静状态几个小时，Autovacuum也不会回来。pg_stat_progress_vacuum显示无活动。pg_stat_activity不显示任何长时间运行的事务。不存在可能阻止自动清空的已放弃的复制插槽或已准备的事务。我们不能在pg_catalog真空表，因为它是由azure超级用户拥有。我们也没有权限查看autovacuum线程是否在操作系统级别运行。
重新启动postgres可以让自动吸尘器再次运行，但从长远来看，这对我们来说不是一个可行的选择。
这里会出什么问题？
1条答案
按热度按时间izkcnapc1#
当你的表停止清理时，你应该检查在
pg_stat_activity中看到了多少autovacuum worker。如果有autovacuum_max_workers那么多，解释是没有空间让你的表被VACUUMed。反环绕式自动吸尘器很可能会导致这种情况，因为这些运行通常比正常的自动吸尘器运行时间更长，资源更密集。您可以通过适当地设置参数来加快反环绕自动清理工作程序的速度，或者可以增加
autovacuum_max_workers以避免使重要表挨饿。这两个选项都将使自动吸尘器使用更多的系统资源。