postgres 14 Vacuumdb 分析階段卡住了幾個小時

Question

我使用 pg_upgrade --link選項從 Postgres 10 升級到 Postgres 14。 數據庫總大小約為 10TB。 pg_upgrade 成功且快速，就像建議的工具一樣 -

Optimizer statistics are not transferred by pg_upgrade. Once you start the new server, consider running: /usr/pgsql-14/bin/vacuumdb --all --analyze-in-stages

我運行了上述命令，但進程卡住了。 作為這種（或不確定，不確定）的副作用，當我創建出版物時，提示永遠不會回來，並且即使經過數小時也不會創建出版物。

postgres=#select * 來自 pg_stat_progress_vacuum;

c1	c2
PID	9520
數據	16402
數據名	xyz
重	22423
階段	吸塵指數
heap_blks_total	232816470
heap_blks_scanned	36766348
heap_blks_vacuumed	0
index_vacuum_count	0
max_dead_tuples	11184809
num_dead_tuples	11184521

這是昨天的output。 我能做些什么來加快這個和“創建出版物”命令？ 附帶說明：運行 Postgres 的 VM 非常強大（64GB RAM，16 核）。 謝謝！

---

編輯1：同一pid的pg_stat_activity的output，

c1	c2
PID	9520
backend_start	2021-12-06 15:13:23.479071-08
xact_start	2021-12-06 15:13:23.512581-08
查詢開始	2021-12-06 15:13:23.512581-08
state_change	2021-12-06 15:13:23.512581-08
等待事件類型	暫停
等待事件	真空延遲
state	積極的
backend_xmin	3140627534
詢問	autovacuum: VACUUM xyz (防止環繞)
后端類型	自動吸塵器

Answer 1

vacuumdb --all --analyze-in-stages不會運行VACUUM ，而是ANALYZE ，所以你必須查看pg_stat_progress_analyze看看它是如何做的。

您看到運行的VACUUM進程與此無關。 這是一個反環繞式真空吸塵器，目前正在休眠，但正在處理中。 讓它結束； 此過程對於數據庫的健康很重要。 如果您希望在該表上進一步運行 autovacuum 以更快地完成，請減少該表的autovacuum_vacuum_cost_delay 。

Answer 2

簡單地升級不應該導致反環繞真空運行，因此它決定在升級后立即運行可能是時間巧合。 另一方面，也許你的新數據庫版本有不同的配置設置，例如autovacuum_freeze_max_age的值較低，使用這個新設置運行是觸發它立即啟動的原因。 您是否將所有非默認配置設置從 v10 轉移到 v14？

我同意 Laurenz 的觀點，確實需要讓它完成，但這並不意味着你需要讓它立即完成。 您可以終止清理后端，以便您的 CREATE PUBLICATION 有機會運行。 autovac 可能會立即重新啟動，因此當您取消真空時，您應該已經嘗試運行 CREATE PUBLICATION。 這樣，它就能夠在真空再次啟動並再次獲取鎖之前獲取鎖。 但是請確保您不會養成每次給您帶來不便時取消真空吸塵器的習慣。

此外，您應該將maintenance_work_mem 增加很多。 看起來它當前設置為 64MB，這對於您描述的服務器來說是相當低的。 如果您將其設置為 1GB，那么它應該能夠只通過索引一次而不是您目前正在准備的七次來清理整個表。 在取消真空之前，我會在 conf 文件中更改此設置並 SIGHUP 服務器，這樣啟動的新真空應該具有新設置。

最后，我不知道為什么這會清除索引。 我認為 v14 改變了它，以便緊急清理不會費心去做，而是凍結堆中的元組並將索引留給以后使用。 我想我需要更多地研究 v14 來弄清楚它在這里的真正作用。