4

我目前正在清理一个具有 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]

再次感谢

4

4 回答 4

5

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

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

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

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

于 2009-01-11T23:39:54.870 回答
4

一些快速提示：

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

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

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

于 2009-01-12T01:15:35.037 回答
0

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

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

于 2009-01-24T00:49:47.473 回答
0

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

Lettssay 你还有一些磁盘空间，这比 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 不支持这个。

于 2011-05-04T16:05:29.067 回答