Postgres 慢查询 - Autovacuum 频率

Question

我们注意到最近几周我们平台的性能下降，所以我运行了以下命令：

select relname, last_vacuum, last_autovacuum, last_analyze, last_autoanalyze 
from pg_stat_user_tables 
where relname like 'core_%';

并注意到我们的主桌已经一个多星期没有自动清扫了。所以上周我跑了：

vacuum analyse verbose TABLENAME

这似乎有帮助，但我们现在又遇到了同样的问题。仔细检查后，很多表要么从未被分析过（自动或其他方式），除了vacuum analyse上周手动运行之外，没有一个表被手动清理过，而且很多其他表也没有被自动清理过，充其量是几天前，更糟的是几周前。

我对条款的理解如下：

• 真空：从磁盘中清除已删除的记录
• 分析：更新查询规划器

在 中postgres.conf，autovacuum 属性被注释掉了，但是文档指出这是默认打开的，所以我的假设是即使它被注释掉了，它仍然应该打开吗？

有人可以解释为什么这些表不会被频繁地清理和分析，更具体地说，这些没有更新的值实际上对系统有那么大的影响吗？

信息：Postgres 9.1 操作系统：Ubuntu 12.04

输出

SELECT relname as "Table",
pg_size_pretty(pg_total_relation_size(relid)) As "Size",
pg_size_pretty(pg_total_relation_size(relid) - pg_relation_size(relid)) as "External Size"
FROM pg_catalog.pg_statio_user_tables 
ORDER BY pg_total_relation_size(relid) DESC;


     Table       | Size | External Size
-----------------+------+---------------
"Primary Table"  | 27G  |     8232M

Answer 1

真空：从磁盘中清除已删除的记录

不完全是。VACUUM将不再对任何活动事务可见的行标记为死行（并准备好重新使用）。它不会缩小代表表的物理文件大小，除了物理端完全死/空的页面。手册解释了一切，可能比我在这里回顾的要好。

分析：更新查询规划器

It's officially ANALYZE, with Z, but ANALYSE is accepted as alternative spelling, too. And it updates statistics used by the query planner. Again, the manual already provides the best explanation.

In postgres.conf ... my presumption is that even though it's commented out, it should still be on?

That's correct. Again, consider details in the manual.

With that many write operations (a few thousand records a minute) your system is in bad need of regular VACUUM / ANALYZE runs. You have read the manual by now, so you understand the consequences. If your table ...

hadn't been autovacuumed for more than a week.

......那么这很糟糕，原因有很多。还要考虑@Daniel 的回答，这可能是如何在像您这样的大桌子上发生的。或者，高负载可能会不断锁定表，并且永远VACUUM不会让其工作。同样，这一切都记录在手册中。这是一个相关案例，很好地回答了如何调整设置：

• PostgreSQL 上的主动式自动清理

请记住，您可以使用per-table设置（存储参数）来微调特殊表的特殊需求，而让系统的其余部分保持不变。

如果您主要更新最近插入的行，则FILLFACTOR低于 100 可能会很有帮助。您可以使用CLUSTER或pg_repack然后设置FILLFACTOR低于 100来压缩表（一次）。对于巨大的表，它也可能有助于为STATISTICS具有不规则数据分布的关键列设置更高的目标。

• 为读取性能配置 PostgreSQL
• 在 9.1 下仍然推荐常规的 VACUUM ANALYZE 吗？

此外，如果旧行很少更新，分区可能是一个很好的解决方案，以区别对待旧部分。这真的取决于完整的图片......

另外，不要忘记索引，它们也会变得臃肿。只保留您实际需要的索引。

要查看死元组和活元组的数量：

• pg_stat_user_tables中n_live_tup和n_dead_tup是什么意思