# 23.1\. 日常清理 PostgreSQL數據庫需要定期/維護被稱為_vacuuming_。 很多安裝足以通過_autovacuum守護進程_執行清理，正如[Section 23.1.6](#calibre_link-77)所描述的。 你可能需要調整清理參數為你的情況得到最好的結果。一些數據庫管理員會想 補充或取代手動管理`VACUUM`命令的進程活動， 這通常根據cron或者任務調度程序腳本執行的。 設置手動管理適當清理，理解下面幾個子部分討論的問題是必要的。依賴于autovacuuming的管理員可能仍然希望 瀏覽此材料來幫助他們理解和調整autovacuuming。 ## 23.1.1\. 清理基礎 PostgreSQL的[VACUUM](#calibre_link-748)命令 由于以下幾個原因，必須周期性處理每個表： 1. 恢復那些由已更新或已刪除的行占據的磁盤空間 2. 更新PostgreSQL查詢規劃器使用的數據統計信息。 3. 更新可見性映射，這加速了唯一索引掃描 4. 避免因為_事務ID重疊_造成的老數據丟失。 對上面每個原因進行`VACUUM`操作的頻率和范圍不同。正如下面 每個部分所述。 有`VACUUM`的兩個變形：標準`VACUUM` 和`VACUUM FULL`。`VACUUM FULL`可以回收更多 磁盤空間，但運行速度要慢得多。另外，`VACUUM`的標準形式可以與生產 數據庫操作并行運行。 （命令`SELECT`,`INSERT`, `UPDATE`和 `DELETE`將繼續正常工作，當被清理的時候，但你使用諸如命令`ALTER TABLE` 將不能夠修改表的定義）。 `VACUUM FULL`需要正運行的表上的排他鎖， 并且不能與其它表使用并行完成。一般地，因此， 管理員應該盡量使用標準的`VACUUM`避免`VACUUM FULL`。 另外，`VACUUM`需要大量的I/O操作，可能導致其它活動中的會話性能嚴重降低。 調整配置參數以降低后端清理的性能影響— 參閱[Section 18.4.4](#calibre_link-752) 獲取更多信息。 ## 23.1.2\. 恢復磁盤空間 在正常的PostgreSQL操作里， 對一行的`UPDATE`或者`DELETE` 并未立即刪除舊版本的數據行。這個方法對于獲取多版本并發控制的好處是必要的 (MVCC參閱[Chapter 13](#calibre_link-444))： 如果一個行的版本仍有可能被其它事務看到，那么你就不能刪除它。 但到了最后，不會有任何事務對過期的或者已經刪除的行感興趣。 而它占據的空間必須為那些新行的使用而回收，以避免對磁盤空間需求無限的增長。 這件事是通過運行`VACUUM`實現的。 `VACUUM`的標準形式刪除表中的死行以及索引，并且標記未來可重新使用的可用空間。 然而，它不會返回空間到操作系統， 除了在特殊情況下，其中表結尾的一個或多個頁面完全自由，并且可輕易獲得排它表鎖。 相比之下，`VACUUM FULL`通過寫入沒有死表空間的表文件完整的新版本來壓縮表， 這最大限度地減少了表的大小，但也需要相當長的時間。 這還需要表的新副本額外的磁盤空間，直到操作完成。 定期清理通常目標是執行標準`VACUUM`通常足以避免需要`VACUUM FULL`。 該自動清理后臺程序試圖以這種方式工作，而事實上 從未提出`VACUUM FULL`。在這種方法中，想法是不能保持表的最小尺寸但要保持磁盤空間用法穩定狀態： 每個表占用的空間相當于其最小尺寸加上清理期間被用完的許多空間。 雖然`VACUUM FULL`可用于收縮表到其最小尺寸， 并返回該磁盤空間給操作系統，如果該表將來只是再次增長，那么毫無意義。 因此，比起為了維護更新頻繁的表而很少運行`VACUUM FULL`來說， 運行適度頻繁標準`VACUUM`是一個好的方法。 某些管理員傾向于定期清理自己，例如當負載較低的時候夜間做所有的工作。 按照固定的時間執行清理的困難是，如果一個表在更新活動中有意想不到的秒殺， 它可能膨脹，所以`VACUUM FULL`的確有必要回收空間。 使用自動清理后臺程序解決了這個問題， 因為守護進程時間表清理動態響應更新活動。 完全禁用守護進程是不明智的，除非你 有一個可預測的工作量。一個可能的妥協是 設置守護進程的參數，這樣只會反應異常沉重的更新活動，從而使事情變得不可收拾， 當負載是典型的，而預定的`VACUUM`希望做更多的工作。 對于那些不使用自動清理的，典型的做法是一旦在低使用率期間的一天安排數據庫范圍的`VACUUM`， 通過更新頻繁的表更加頻繁的清理作為必要補充。 （有些具有極高更新速率的安裝每隔幾分鐘清理他們最繁忙的表）。 如果你在集群中有多個數據庫，則不要忘了`VACUUM`; 該程序[vacuumdb](#calibre_link-754)可能會有所幫助。 > **Tip:** 普通`VACUUM`可能不盡如人意， 當一個表中包含大量的死行版本作為大規模更新或刪除活動的結果。 如果你有這樣一個表，并且你需要回收占用的多余磁盤空間，則需要 使用`VACUUM FULL`，或者[CLUSTER](#calibre_link-71) 或者[ALTER TABLE](#calibre_link-88)的表重寫變形之一。 這些命令重寫表的全新副本，并建立新的索引。 所有這些選項都需要排它鎖。需要注意的是他們也暫時使用額外的磁盤空間大致等于表的大小， 因為表的舊副本以及索引不能釋放，直到新的完成。 > **Tip:** 如果你有一個表，它的內容經常被完全刪除， 那么可以考慮用[TRUNCATE](#calibre_link-89)而不是后面跟著`VACUUM`‘ 的`DELETE`。 `TRUNCATE`立即刪除整個表的內容， 而不要求隨后的`VACUUM`或者`VACUUM FULL` 來恢復現在未使用的磁盤空間。 缺點是違反了嚴格的MVCC語義。 ## 23.1.3\. 更新規劃器統計 PostgreSQL的查詢規劃器依賴一些有關表內容的統計信息用以為查詢生成好的規劃。 這些統計是通過[ANALYZE](#calibre_link-589)命令獲得的， 你可以直接調用這條命令，也可以把它當做 `VACUUM`里的一個可選步驟來調用。擁有合理準確的統計是非常重要的，否則， 選擇了惡劣的規劃很可能降低數據庫的性能。 如果啟用自動清理后臺程序，將自動發出`ANALYZE`命令，當表的內容已經充分改變。 然而，管理員可能更愿意依靠手動安排的`ANALYZE`操作，尤其是 如果它是已知的表上的更新活動，不會影響 "感興趣"列的統計。守護進程時間表 `ANALYZE`嚴格作為插入或更新行數的函數; 它不知道是否這將導致有意義的統計變化。 和為了回收空間做清理一樣，經常更新統計信息也是對更新頻繁的表更有用。 不過，即使是更新非常頻繁的表，如果它的數據的統計分布并不經常改變， 那么也不需要更新統計信息。 一條簡單的拇指定律就是想想表中字段的最大跟最小值改變的幅度。 比如，一個包含行更新時間的`timestamp`字段將隨著行的追加和更新穩定增長最大值； 這樣的字段可能需要比那些包含訪問網站的URL的字段更頻繁一些更新統計信息。 那些URL字段可能改變得一樣頻繁，但是其數值的統計分布的改變相對要緩慢得多。 我們可以在特定的表，甚至是表中特定的字段上運行`ANALYZE`， 所以如果你的應用有需求的話，可以對某些信息更新得比其它信息更頻繁。 不過，在實際中，通常最好只是分析整個數據庫，因為它是一個快速操作。 `ANALYZE`使用了統計學上的隨機采樣的方法進行行采樣， 而不是把每一行都讀取進來。 > **Tip:** 盡管用`ANALYZE`針對每個字段進行挖掘的方式可能不是很實用， 但你可能還是會發現值得針對每個字段對`ANALYZE` 收集的統計信息的詳細級別進行調整。 那些經常在`WHERE`子句里使用的字段如果有非常不規則的數據分布， 那么就可能需要比其它字段更細致的數據圖表。 參閱`ALTER TABLE SET STATISTICS`。或者使用[default_statistics_target](#calibre_link-979) 配置參數改變缺省數據庫。 > > 另外，默認情況下有選擇性函數的有限信息可用。但是， 如果您使用函數調用創建一個表達式索引，有用的統計數據將 收集有關函數的信息，這樣可以使用表達式索引大大提高查詢規劃。 > **Tip:** 該自動清理后臺程序不會為外表發出`ANALYZE`命令， 因為它沒有辦法決定多長時間可能是有用的。如果您的查詢需要外表的統計信息進行適當的規劃， 在表上合適的時間運行手動管理`ANALYZE`命令是一個好主意。 ## 23.1.4\. 更新可見視圖 清理保持[可見視圖](#calibre_link-1513)為了每個表跟蹤只包含元組的頁面， 對所有活動事務可見（以及所有未來的事務，直至頁面再次修改）。這有兩個目的。首先，在下次運行時清理 本身可以跳過這些頁面，因為沒有什么可清理的。 其次，它允許PostgreSQL回答一些只使用索引，沒有參考基礎表的查詢。 由于PostgreSQL索引不包含能見度信息元組 ，普通索引掃描為每個匹配索引項抓取堆元組， 檢查它是否由當前事務可見。另外一方面，_索引掃描_首先檢查 能見度視圖。如果它知道，頁面上的所有元組是 可見的，可用忽略堆抓取。在大型數據集上這是最顯著的。 其中可見視圖可以防止磁盤訪問。 可見視圖遠遠比堆小，所以即使堆非常大，它可以很容易地緩存。 ## 23.1.5\. 避免事務ID重疊造成的問題 PostgreSQL的MVCC事務語意依賴于比較事務 ID(XID)的數值： 一條帶有大于當前事務XID的插入XID的行版本是"屬于未來的"， 并且不應為當前事務可見。但是因為事務ID的大小有限(在我們寫這些的時候是32位)， 如果集群一次運行的時間很長(大于40億次事務)，那么它就要受到_事務ID重疊_的折磨： XID計數器回到零位，然后突然間所有以前的事務就變成看上去是在將來的— 這意味著它們的輸出將變得可見。簡而言之，可怕的數據丟失。實際上數據仍然在那里， 但是如果你無法獲取數據，這么說也只是自我安慰罷了。 為了避免這種情況，有必要清理至少每二十億事務的每個數據庫中的每個表。 周期性的運行VACUUM可以解決這個問題的原因在于PostgreSQL 可以儲存特殊的XID(`FrozenXID`)。這個XID不遵循普通XID比較規則， 總是被認為比任何普通的XID舊。 普通的XID使用模-2<sup class="calibre28">31</sup>算法進行比較。 這就意味著對于每個普通的XID， 總是有二十億個XID是"更舊"以及二十億個XID"更新"； 表達這個意思的另外一個方法是普通的XID 空間是沒有終點的環。因此，一旦某行帶著特定的普通XID創建出來， 那么該行將在以后的二十億次事務中表現得是"在過去"，而不管我們說的是哪個普通XID。 如果該行在超過二十億次事務之后仍然存在，那么它就會突然變成在將來的行。 為了避免數據丟失，老的行必須在到達二十億次事務的年齡之前的某個時候賦予`FrozenXID`。 一旦它被賦予了這個特殊的XID ，那么它們在所有普通事務面前表現為"在過去"， 而不管事務ID是否重疊，因此這樣的行不管保存多長時間，直到刪除之前都會完好。 這個XID的重新賦值是`VACUUM`控制的。 [vacuum_freeze_min_age](#calibre_link-750) 控制著在它之前更舊的XID將被替換為`FrozenXID`。 較大的設置值防止了事務信息變長， 較小的值增加了在表必須被清理之前可以清理事務的數量。 `VACUUM`通常會忽略沒有任何死行版本頁面， 但這些頁面可能仍然有舊XID值的行版本。為了確保所有舊的XID已被`FrozenXID`替換， 需要全表掃描。[vacuum_freeze_table_age](#calibre_link-97)控制 `VACUUM`的執行：為了`vacuum_freeze_table_age` 減去`vacuum_freeze_min_age`事務，如果沒有完全掃描整個表， 則將其設置為0，強制`VACUUM`總是掃描所有頁面，有效地忽略可見視圖。 表在清理之前允許執行的最大事務次數 是20億事務減去`VACUUM`上次掃描整個表時的`vacuum_freeze_min_age`值。 如果超過這個限制就很可能造成數據丟失。為了保證數據安全， 必須在任何可能包含舊于[autovacuum_freeze_max_age](#calibre_link-96)指定的XID的 表上調用autovacuum。甚至在autovacuum被禁用的情況下也可以調用。 這就意味著，一個未被清理的表將會在大約`autovacuum_freeze_max_age` 減去`vacuum_freeze_min_age`次事務后被自動清理。 對于那些周期性清理以回收空間的表來說，這個并不重要。 對于靜態表(包括只插入不更新/刪除的表)，因為不需要回收空間的清理， 所以可以嘗試最大化強制清理的時間間隔， 也就是增加`autovacuum_freeze_max_age`的值或 減少`vacuum_freeze_min_age`的值。 `vacuum_freeze_table_age`有效最大值是0.95*`autovacuum_freeze_max_age`; 高于它的設置將覆蓋最大值。高于`autovacuum_freeze_max_age`的值是沒有意義的， 因為自動清理將在這一點被觸發，在這發生之前，0.95乘數留下一些空間來執行手動 `VACUUM`。作為一個經驗法則，`vacuum_freeze_table_age`應設置為稍微低于`autovacuum_freeze_max_age`的一個值。 留出足夠的空隙，以便定期安排`VACUUM`或通過運行在該窗口中的正常刪除和更新活動觸發自動清理。 將其設置得接近可能導致抗回繞自動清理， 即使表最近被清理以回收空間，而較低的值會導致更多頻繁的全表掃描。 增加`autovacuum_freeze_max_age`以及`vacuum_freeze_table_age` 的唯一不利之處在于數據庫集群的`pg_clog`子目錄將會占用更多空間， 因為它必須為所有`autovacuum_freeze_max_age`之后的事務存儲提交狀態。 每個事務提交狀態使用2字節，因此如果`autovacuum_freeze_max_age` 設置為最大允許值為20億，`pg_clog`將會增加到大約500M。 如果這個尺寸比起你的數據庫來只是小菜一碟，我們推薦你將 `autovacuum_freeze_max_age`設為允許的最大值。否則， 如何設置將取決于你愿意給`pg_clog`多大的空間。默認值是2億， 大約需要50MB的`pg_clog`存儲空間。 減小`vacuum_freeze_min_age` 的不利之處是可能導致`VACUUM`做無用功： 如果行在不久之后就被修改，那么將XID修改為`FrozenXID`就是在浪費時間， 因為它很快就將獲得一個新的XID。 因此這個設置應當足夠大以使得行不被過早的凍結。 減小`vacuum_freeze_min_age`的另一個不利之處 是事務插入或修改行的準確細節將會很快丟失。 這個信息有時遲早會派上用場， 特別是數據庫失敗之后分析究竟發生了什么錯誤的時候。 因為這兩個原因，在完全靜態的表上減小這個值是不明智的。 為了跟蹤數據庫中最老的XID壽命， `VACUUM`在系統表`pg_class`和`pg_database` 里存儲了XID統計。 尤其是一個數據庫的`pg_class`行中的`relfrozenxid`字段 包含了最后一個整表`VACUUM`命令使用的凍結終止XID。 系統保證在該表中所有比這個終止XID老的普通XID都被`FrozenXID`代替。 同樣，一個數據庫的`pg_database`行中的`datfrozenxid` 字段是普通XID的下界— 它只是數據庫中每個表`relfrozenxid`的最小值。 檢查這個信息的一個便利方法是執行下面的查詢： ``` SELECT c.oid::regclass as table_name, greatest(age(c.relfrozenxid),age(t.relfrozenxid)) as age FROM pg_class c LEFT JOIN pg_class t ON c.reltoastrelid = t.oid WHERE c.relkind IN ('r', 'm'); SELECT datname, age(datfrozenxid) FROM pg_database; ``` `age`字段用于測量從中止XID到當前事務XID的數目。 `VACUUM`常常只掃描自上次清理已被修改的頁， 但`relfrozenxid`僅僅提前掃描整個表。當`relfrozenxid`大于 `vacuum_freeze_table_age`事務時，當使用`VACUUM`的`FREEZE`選項時， 或者當所有頁需要清理刪除死行版本，進行全表掃描。 當`VACUUM`掃描全表時， `age(relfrozenxid)`應當立即使用稍微大于`vacuum_freeze_min_age`的值 (比`VACUUM`啟動之后開始的事務數目稍大)。如果在表上提出非全表掃描`VACUUM`直到 超過`autovacuum_freeze_max_age`，則將會很快在表上強制進行自動清理。 如果從表中清理舊XID失敗，那么當數據庫的舊XID到達1000萬以后， 系統將發出類似下面這樣的警告信息： ``` WARNING: database "mydb" must be vacuumed within 177009986 transactions HINT: To avoid a database shutdown, execute a database-wide VACUUM in "mydb". ``` 手動`VACUUM`應該修復這個問題，正如提示建議；但是注意`VACUUM` 必須通過超級用戶執行，否則無法處理系統目錄，并且不能提高數據庫的`datfrozenxid`。 如果忽略了上面的警告信息，那么系統將在距離重疊小于100萬次的時候關閉， 并且拒絕開始任何新的事務： ``` ERROR: database is not accepting commands to avoid wraparound data loss in database "mydb" HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb". ``` 這個100萬的事務安全邊界留下來用于讓管理員在不丟失數據的情況下進行恢復， 方法是手工執行所需要的`VACUUM`命令。不過，因為一旦進入了安全關閉模式， 系統就不能再執行命令，做這件事情的唯一的方法是停止主服務器， 使用一個單獨運行的后端來執行`VACUUM`。關閉模式不會強制于獨立運行的后端。 參閱[postgres](#calibre_link-1033)手冊獲取有關使用獨立運行后端的細節。 ## 23.1.6\. Autovacuum守護進程 PostgreSQL帶有一個可選高度推薦的特性 叫做_autovacuum_守護進程， 它的目的是自動執行`VACUUM`和`ANALYZE` 命令。 在打開這個選項之后，autovacuum守護進程將檢查那些有大量插入、 更新、刪除行操作的表。這些檢查使用行級別的統計收集設施；因此，除非把 [track_counts](#calibre_link-1454)設置為`true`， 否則無法使用autovacuum守護進程。 在缺省配置下，啟用autovacuum守護進程并且合理設置相關配置參數。 該"自動清理后臺程序"實際上是由多個進程組成的。 有一個持久守護進程，稱為_autovacuum launcher_ 它是負責為所有數據庫啟動_autovacuum worker_進行。 該發射器將分發工作跨越時間， 每個數據庫內每[autovacuum_naptime](#calibre_link-1622)秒內嘗試啟動1個工作。 （因此，如果安裝有`_N_`個數據庫，每`autovacuum_naptime`/`_N_`秒將開始一個新的。） 最多[autovacuum_max_workers](#calibre_link-1372)工作進程在同一時間允許運行。 如果正在處理多于`autovacuum_max_workers`的數據庫，一旦第一個處理完成將處理 下一個數據庫。每個工作進程將檢查它的數據庫中的每個表，并且 執行`VACUUM`和/或者按需要執行`ANALYZE`。 使用`log_autovacuum_min_duration`可以監控 自動清理活動。 如果在很短的時間中需要清理若干個大表，則 所有自動清理的工人可能需要很長一段時間清理這些表。 這將導致其它表和數據庫不能被清理，直到工人可用。 在單一的數據庫中有多少人可能沒有限制， 但盡量避免已經被其他人完成的重復工作。需要注意的是運行數 不計入[max_connections](#calibre_link-441)或者 [superuser_reserved_connections](#calibre_link-1623)限制。 那些`relfrozenxid`大于[autovacuum_freeze_max_age](#calibre_link-96) 的表將總是被清理（這也適用于通過存儲參數修改的凍結最大時間的那些表；參見下文）。 否則，如果上次`VACUUM`之后的過期行的數量超過了"清理閾值"， 那么就清理該表。清理閾值定義為: ``` vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuples ``` 這里的清理基本閾值是[autovacuum_vacuum_threshold](#calibre_link-1624)， 清理縮放系數是[autovacuum_vacuum_scale_factor](#calibre_link-1625)， 行數是`pg_class`.`reltuples`， 過期行的數量是從統計收集器里面獲取的， 這是一個半精確的計數，由每次`UPDATE`和`DELETE`操作更新。 半精確的原因是在重負載時有些信息可能會丟失。 如果表的`relfrozenxid`值大于`vacuum_freeze_table_age`，掃描整個表 凍結舊元組，并且提升`relfrozenxid`，否則僅僅掃描上次清理后修改的頁。 為了分析，使用了一個類似的條件：分析閾值，定義為： ``` analyze threshold = analyze base threshold + analyze scale factor * number of tuples ``` 它會和上次`ANALYZE`插入、更新、刪除的總行數進行比較。 臨時表不能被自動清理進行訪問。因此，適當的清理和分析操作應通過會話SQL命令執行。 缺省的閾值和伸縮系數是從`postgresql.conf`里面取得的，不過， 它可能基于表而覆蓋。參閱[_存儲參數_](#calibre_link-86)獲取更多細節。 如果通過存儲參數已經改變設置，那么則使用該值；否則使用全局設置。 參閱[Section 18.10](#calibre_link-1249)獲取有關全局設置的更多細節。 除了基本閾值和縮放系數之外， 還有6個autovacuum 參數可以通過存儲參數為每個表進行設置。 第一個參數，`autovacuum_enabled`可以設置為`false`讓autovacuum 守護進程完全忽略某個表。這種情況下，autovacuum只有在為了避免事務ID 重疊必須清理整個數據庫的時候才會動那個表。接下來兩個參數， `autovacuum_vacuum_cost_delay`和`autovacuum_vacuum_cost_limit` 用于針對特定的表為基于開銷的清理延遲特性設置數值。參閱[Section 18.4.4](#calibre_link-752)。 `autovacuum_freeze_min_age`, `autovacuum_freeze_max_age`和 `autovacuum_freeze_table_age`分別為[vacuum_freeze_min_age](#calibre_link-750), [autovacuum_freeze_max_age](#calibre_link-96)和 [vacuum_freeze_table_age](#calibre_link-97)設置數值。 當多個工作者正在運行，成本限制在所有正在運行的人中是"balanced"， 從而使系統上的總影響是相同的，而不管實際運行人數。