PostgreSQL 长真空答案

【问题标题】：PostgreSQL Long VACUUMPostgreSQL 长真空
【发布时间】：2009-01-11 21:22:17
【问题描述】：

我目前正在清理一个包含 2 个索引和 2.5 亿个活动行以及大约相同数量（或更多）的死行的表。我从我的客户端计算机（笔记本电脑）向我的服务器发出了命令 VACCUM FULL ANALYZE。它在过去 3-4 天左右一直在开展业务；我想知道它是否会很快结束，因为我还有很多工作要做！

服务器有一个四码 Xeon 2.66 GHz 处理器、12 GB 或 RAM 和一个 RAID 控制器，连接到 RAID 1 配置中的 2 个 10K rpm 146 GB SAS HD；它正在运行 Suse Linux。我想知道...

现在，首先，VACUUM postmaster 进程似乎只使用一个核心。其次，我没有看到非常高的 I/O 写入与 I/O 空闲时间的比率。第三，通过调用procinfo，我可以推断出 VACUUM 进程大部分时间 (88%) 都在等待 I/0。

那么为什么不通过线程利用更多内核来使 RAID 控制器过载（获得高 I/O 写入空闲比）？如果 I/O 负载不高，为什么还要等待 I/O？为什么所有这些权力/资源都掌握在自己手中，速度却没有更快？在我看来，VACUUM 可以而且应该是多线程的，特别是如果它在一张巨大的桌子上工作并且它是唯一工作的！

另外，他们是否可以配置 postgresql.conf 以使其多线程这样的 VACUUM？我可以杀死它并仍然从它的部分清理中受益吗？我需要在那张桌子上工作。

[我使用的是 PostgreSQL 8.1]

再次感谢

【问题讨论】：

标签： postgresql rdbms vacuum

【解决方案1】：

你没有说你使用的是什么版本的 PostgreSQL。有可能是8.0之前的吗？

我遇到了完全相同的情况。你最好的：

杀死真空
使用 pg_dump -t 选项备份表
删除表
恢复表

如果您使用的是 8.x，请查看 autovacuum 选项。 Vacuum 是单线程的，你无法让它使用多线程。

【讨论】：

你说先杀了vacuum再备份表，VACUUM死了会有什么结果？我喜欢你关于删除和恢复的想法。谢谢
vacuum 被杀死时没有什么不好的事情发生，你只是失去了到目前为止回收表空间所做的工作。我们有一项工作会在早上 8:00 自动关闭所有真空吸尘器，这样用户进来时就不会被卡住。如果发生这种情况，我们将在第二天晚上转储/恢复。
从现在开始设置一个用于清理的 cron 作业可能是个好主意。
集群而不是全真空会更好吗？

【解决方案2】：

一些快速提示：

运行 VACUUM FULL VERBOSE，以便您了解正在发生的事情。
删除 VACUUM 之前的所有索引。重建它们比吸尘它们更快。您还需要不时重建它们，因为 VACUUM FULL 不够好（尤其是在像 8.1 这样的旧 PosgreSQL 上）。
将maintenance_work_mem 设置得非常高。
使用较新的 PostgreSQL。顺便说一句，8.4 将在吸尘方面有了巨大的改进。

VACUUM 的替代方法是转储和恢复。

编辑：自 9.0 起，VACUUM FULL 重写了整个表。基本上和dump + restore是一样的，所以不需要运行REINDEX。

【讨论】：

【解决方案3】：

您确定没有任何正在进行的事情可以锁定表并阻止真空运行吗？

（无论如何，最好使用vacuum_cost_delay，这样真空不会对生产造成干扰。）

【讨论】：

【解决方案4】：

旧 VACUUM FULL 是化石。它也很慢，之后您必须使用 REINDEX。不要使用它。如果你真的想对表进行碎片整理，请使用 CLUSTER，或者这样：

假设你还有一些磁盘空间，这比 dump&reload 快得多：

CREATE TABLE newtable AS SELECT * FROM oldtable;
CREATE INDEX bla ON newtable( ... );
ALTER TABLE oldtable RENAME TO archive;
ALTER TABLE newtable RENAME TO oldtable;

请注意，这不会复制您的约束。您可以使用 CREATE TABLE LIKE ... 来复制它们。

那么为什么不通过线程利用更多内核

pg 不支持这个。

【讨论】：