Postgres 慢查詢 - Autovacuum 頻率

我們注意到最近幾週我們平台的性能下降了，所以我執行了以下命令：

select relname, last_vacuum, last_autovacuum, last_analyze, last_autoanalyze 
from pg_stat_user_tables 
where relname like 'core_%';

並註意到我們的主表已經有一個多星期沒有被自動清空了。所以上週我跑了：

vacuum analyse verbose TABLENAME

這似乎有所幫助，但我們現在又遇到了同樣的問題。經過仔細檢查，很多表要麼從未被分析過（自動或其他），除了vacuum analyse上週手動執行之外，沒有一個表被手動清理過，而且很多其他的表也沒有被自動清理過，充其量是幾天前，更糟糕的是幾週前。

我對條款的理解如下：

• 真空：從磁碟中清除已刪除的記錄
• 分析：更新查詢計劃器

在postgres.conf中，autovacuum 屬性被註釋掉了，但是文件說明這是預設開啟的，所以我的假設是即使它被註釋掉了，它仍然應該開啟？

有人可以解釋為什麼這些表不會被頻繁地清理和分析，更具體地說，這些沒有更新的值實際上會對系統產生那麼大的影響嗎？

資訊：Postgres 9.1 作業系統：Ubuntu 12.04

的輸出

SELECT relname as "Table",
pg_size_pretty(pg_total_relation_size(relid)) As "Size",
pg_size_pretty(pg_total_relation_size(relid) - pg_relation_size(relid)) as "External Size"
FROM pg_catalog.pg_statio_user_tables 
ORDER BY pg_total_relation_size(relid) DESC;


    Table       | Size | External Size
-----------------+------+---------------
"Primary Table"  | 27G  |     8232M

真空：從磁碟中清除已刪除的記錄

不完全是。VACUUM將不再對任何活動事務可見的行標記為已死（並準備好重新使用）。它不會縮小代表表的物理文件大小，除了物理端完全死/空的頁面。該手冊解釋了一切，可能比我在這裡概括的要好。

分析：更新查詢計劃器

它是正式的ANALYZE, Z, 但ANALYSE也被接受為替代拼寫。它會更新查詢計劃*器使用的統計資訊。*同樣，該手冊已經提供了最好的解釋。

在postgres.conf…我的假設是，即使它已被註釋掉，它仍然應該打開？

這是正確的。再次考慮手冊中的細節。

有了這麼多的寫入操作（每分鐘幾千條記錄），您的系統非常需要定期VACUUM/ANALYZE執行。您現在已經閱讀了手冊，因此您了解後果。如果你的桌子…

一個多星期沒有自動吸塵了。

…那麼由於多種原因，這很**糟糕。**還要考慮@Daniel 的回答，像你這樣的大桌子可能會發生這種情況。或者，高負載可能會不斷鎖定表，並且永遠VACUUM不會讓它工作。同樣，這一切都記錄在手冊中。這是一個相關案例，其中包含如何調整設置的好答案：

• PostgreSQL 上的主動自動清理

請記住，您可以通過per-table設置（儲存參數）來微調特殊表的特殊需求，而無需理會系統的其餘部分。

如果您主要更新最近插入的行，FILLFACTOR則低於 100 可能會很有幫助。CLUSTER您可以使用或pg_repack然後設置低於 100來壓縮表（一次）FILLFACTOR。對於大型表，它還可能有助於為STATISTICS具有不規則數據分佈的關鍵列設置更高的目標。

• 為讀取性能配置 PostgreSQL
• 在 9.1 下是否仍建議使用正常 VACUUM ANALYZE？

此外，如果舊行很少更新，分區可能是一個很好的解決方案，以區別對待舊部分。這真的取決於完整的畫面……

另外，不要忘記索引，它們也會變得臃腫。只保留您實際需要的索引。

要查看死元組和活元組的計數：

• pg_stat_user_tables中的n_live_tup和n_dead_tup是什麼意思

引用自：https://dba.stackexchange.com/questions/99055