PostgreSQL長真空

我目前正在清理一個有2個索引和2億5千萬活動行的表，並且大約有許多死行（或更多）。我從我的客戶端計算機（筆記本電腦）向我的服務器發佈了命令VACCUM FULL ANALYZE。它在過去的3-4天左右一直在進行其業務;我想知道它是否會很快結束，因爲我有很多工作要做！PostgreSQL長真空

該服務器採用四核Xeon 2.66 GHz處理器，12 GB或RAM，RAID控制器連接到RAID 1配置中的2 x 10K rpm 146 GB SAS HD;它正在運行Suse Linux。我在想...

現在，首先，VACUUM postmaster過程似乎只使用一個內核。其次，我沒有看到I/O寫入I/O空閒時間比例非常高。第三，從調用procinfo，我可以推斷出VACUUM進程花費大部分時間（88％）等待I/O。

那麼，爲什麼它不通過線程利用更多的內核來使RAID控制器過載（獲得高I/O寫入空閒率）呢？爲什麼在I/O負載不高的情況下等待I/O？它的手指上的所有這些能量/資源爲什麼不會更快？在我看來，VACUUM可以並且應該是多線程的，特別是如果它在一張巨大的桌子上工作，而且它是唯一可以工作的！

此外，他們的方式來配置postgresql.conf讓它多線程這樣的VACUUMs？我可以殺死它並仍然從其部分清理中受益嗎？我需要在那張桌子上工作。

[我使用PostgreSQL 8.1]

THX再次

來源

2009-01-11 Nicholas Leonard

你不說你使用的是什麼版本的PostgreSQL。它有可能是8.0之前的版本嗎？

我有這個完全相同的場景。你最好最好的：

殺真空
回來了pg_dump的-t選項
表刪除表
如果您正在使用8.x中恢復表

，看看autovacuum選項。真空是單線程的，沒有什麼可以讓它使用多線程。

來源

2009-01-11 23:39:54

你說要殺死真空然後備份桌子，VACUUM的死亡會導致什麼結果？我喜歡你的下降和恢復的想法。 Thx – 2009-01-11 23:53:47

當真空被殺時，沒有什麼不好的事情發生，你只是失去了回收表空間到目前爲止所做的工作。我們有一項工作可以在上午8:00自動殺死任何真空，這樣用戶在進入時不會卡住。如果發生這種情況，我們會在第二天晚上轉儲/恢復。 – 2009-01-13 00:41:00

一些快速提示：

運行VACUUM FULL VERBOSE這樣你就可以本身是怎麼回事。
刪除VACUUM前的所有索引。重建它們比抽真空要快。你還需要現在重建它們，然後因爲VACUUM FULL不夠好（特別是在像8.1這樣舊的PosgreSQL上）。
設置maintenance_work_mem確實很高。
使用更新的PostgreSQL。順便說一下，8.4將會在吸塵方面有巨大的進步。

VACUUM的替代方法是轉儲和恢復。

編輯：自9.0 VACUUM FULL重寫整個表。這與做dump + restore基本相同，所以運行REINDEX是不必要的。

來源

2009-01-12 01:15:35

您確定您沒有任何可以鎖定桌子並阻止真空運行的東西嗎？

（不管怎麼說，這是最好使用vacuum_cost_delay使真空不中斷生產。）

來源

2009-01-24 00:49:47 user57991

的老式真空FULL是化石。它也很慢，而且之後你需要REINDEX。不要使用它。如果你真的想碎片整理表，使用羣集，或者這樣：

Lettssay你必須留有一定的磁盤空間，這遠遠快於傾倒&重裝：

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-04 16:05:29 peufeu

PostgreSQL長真空

回答

相關問題