PostgreSQL 长真空

Question

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

该服务器具有四代码 Xeon 2.66 GHz 处理器、12 GB 或 RAM 以及一个 RAID 控制器，该控制器连接到 RAID 1 配置中的 2 个 10K rpm 146 GB SAS 硬盘；它运行的是 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]

再次感谢

Answer 1

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

我也遇到过同样的情况。你最好的最好的：

• 杀死真空
• 使用 pg_dump -t 选项备份表
• 放下桌子
• 恢复表

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

Answer 2

一些快速提示：

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

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

编辑：从 9.0 开始 VACUUM FULL 重写整个表。这与执行转储 + 恢复基本相同，因此无需运行 REINDEX。

Answer 3

你确定你没有任何可以锁定桌面并阻止真空运行的东西吗？

（无论如何，最好使用 vacuum_cost_delay ，以便真空不会对生产造成破坏。）

Answer 4

Old VACUUM FULL是一个化石。它也很慢，之后你得到了REINDEX。不要使用它。如果您真的要对表进行碎片整理，请使用CLUSTER，或者：

假设你剩下一些磁盘空间，这比dump <！> amp; 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不支持此。