PostgreSQL 15: stats collector程式最佳化掉了

PG15對統計進行了重大改進。將stats collector程式最佳化掉了，不再將統計資料放入臨時檔案中，而是放到共享記憶體中，在shutdown前由checkpoint程式將其持久化，啟動時由startup程式將其載入。減少了IO和程式間通訊，從而改進效能。

正文

嘗試使用 PG15的使用者都會發現有一個後臺程式消失了：

postgres    1710       1  0 04:03 ?        00:00:00 /usr/pgsql-15/bin/postmaster -D /var/lib/pgsql/15/data/
postgres    1711    1710  0 04:03 ?        00:00:00 postgres: logger 
postgres    1712    1710  0 04:03 ?        00:00:00 postgres: checkpointer 
postgres    1713    1710  0 04:03 ?        00:00:00 postgres: background writer 
postgres    1715    1710  0 04:03 ?        00:00:00 postgres: walwriter 
postgres    1716    1710  0 04:03 ?        00:00:00 postgres: autovacuum launcher 
postgres    1717    1710  0 04:03 ?        00:00:00 postgres: logical replication launcher

PG14及其之前的版本：

postgres    1751       1  0 04:04 ?        00:00:00 /usr/pgsql-14/bin/postmaster -D /var/lib/pgsql/14/data/
postgres    1752    1751  0 04:04 ?        00:00:00 postgres: logger 
postgres    1754    1751  0 04:04 ?        00:00:00 postgres: checkpointer 
postgres    1755    1751  0 04:04 ?        00:00:00 postgres: background writer 
postgres    1756    1751  0 04:04 ?        00:00:00 postgres: walwriter 
postgres    1757    1751  0 04:04 ?        00:00:00 postgres: autovacuum launcher 
postgres    1758    1751  0 04:04 ?        00:00:00 postgres: stats collector 
postgres    1759    1751  0 04:04 ?        00:00:00 postgres: logical replication launcher

是的， “stats collector”消失了。主要瓶頸一去不復返了。

Stats collector程式作用？

新手使用者可能想知道這個程式是什麼？為什麼 PG14及之前版本需要。有一些使用者可能還會和對用於查詢計劃的表級統計資訊採集（ANALYZE）感到迷惑。但這是不同的。PG跟蹤每個程式的所有活動以獲得累積統計資訊，例如掃描表或索引的次數，或者最後一次vacuum或自動vacuum在表上的執行時間，或者自動vacuum在表上執行次數。所有資訊統計收集的資料可以透過不同的pg_stat_*檢視獲得。

有什麼問題？

會話的每個後臺程式都是一個獨立的 PG程式，採集統計資訊和傳輸不是一個簡單的任務。每個後臺程式將他們的活動資訊傳送給單獨的“stats collector”程式。透過UDP包進行通訊。這種方法有很多問題，不是一個可擴充套件的模型。使用者經常報告不同型別的問題，如1）過時的統計資訊，2）stats collector未執行，3）autovacuum無法工作/啟動等。

如果 stats collector在某一個機器上發生問題，很難解釋理解出了什麼問題。

Stats collector另一個缺點是它引起的IO。如果啟用DEBUG級別2，可以在日誌中看到：

2022-08-22 03:49:57.153 UTC [736] DEBUG:  received inquiry for database 0
2022-08-22 03:49:57.153 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/global.stat"
2022-08-22 03:49:57.153 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/db_0.stat"
2022-08-22 03:49:57.168 UTC [1278] DEBUG:  autovacuum: processing database "postgres"
2022-08-22 03:49:57.168 UTC [736] DEBUG:  received inquiry for database 13881
2022-08-22 03:49:57.168 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/global.stat"
2022-08-22 03:49:57.168 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/db_13881.stat"
2022-08-22 03:49:57.169 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/db_0.stat"

可能導致資料目錄所在的掛載點產生大量 IO。由引數stats_temp_directory控制，許多系統上將pg_stat_tmp位於資料目錄中。在ubuntu/debian上位於/var/run/postgresql，例如：

postgres=# show stats_temp_directory ;
          stats_temp_directory           
-----------------------------------------
 /var/run/postgresql/14-main.pg_stat_tmp
(1 row)

PG15新功能

現在，統計資訊不再使用檔案和檔案系統，而是使用動態共享記憶體 。可以參考 Andres Freund的commit摘要：

以前， stats collector透過UDP接收統計更新，並透過定期將統計資料寫入臨時檔案來共享統計資料。這些檔案可以達到數十兆位元組，冰箱每秒最多寫入2次。這就一再阻止我們新增其他有用的統計資料。

現在統計資料儲存在共享記憶體。 variable-numbered物件統計資訊儲存在以dshash雜湊表中（動態共享記憶體）。Fixed-numbered統計儲存在普通共享記憶體中。

Pgstat.c的標頭檔案中有架構的概述。Stats collector不再需要了，可以移除。

利用事務統計丟掉 infrastructure（之前commit統計條目引入）不能再洩漏。之前透過pg_stat_vacuum_stat()刪除洩漏的統計（被[auto-]vacuum呼叫）。在有許多小表的系統中pgstat_vacuum_stat()代價非常昂貴。

現在對於刪除的物件，副本刪除統計資訊條目，當從一個乾淨的 shut down副本開始就不再需要進行統計重置。

很明顯， stats_temp_directory引數棄用了。我們不再需要pg_stat_tmp目錄。但是，保留這個目錄不會破壞pg_stat_statements類似的外掛使用。他們依賴於這個目錄。例如，我們載入pg_stat_statements庫，目錄中會出現一個檔案：

$ ls pg_stat_tmp/
pgss_query_texts.stat

新架構中，大多數統計更新首先在每個程式中累積為 “待處理”（每個後端都有一個本地雜湊表）。“待定”是指他們已累積，但尚未提交到共享統計系統。稍後會在提交或超時後重新整理到共享記憶體。

由於統計資料會在有人嘗試閱讀時同時更新。因此就出現了讀取一致性問題。所以 PG15引入了一個新引數stats_fetch_consistency，可以取值none，cache或snapshot。

“none”是最高效的，但不會提供一致性讀。“cache”確保欄位能夠重複訪問到相同值，在self-join相關的查詢中非常必要。“snapshot”在互動式檢查統計資訊時很有用，但開銷較大。預設是“cache”。

如果他在共享記憶體，如果在重啟後沿用

關機前由 checkpoint整合寫出到檔案系統，並在啟動程式啟動期間再次載入。像往常一樣，如果發生崩潰，統計資訊將會被丟棄。

會影響我的監控工具 /指令碼嗎

所有統計資料監控檢視 pg_stat_*繼續按原樣工作。但請確保為stat_fetch_consistency。如上所述，保留pg_stat_tmp目錄不會破壞使用這種方法開發的外掛。但是外掛開發人員需要針對PG15徹底進行測試。

還有什麼

像我這樣使用 PG　wait events來了解PG和他的會話在哪裡花費了時間。我們在日常生活中使用pg_gather類似的資料採集分析工具。引入了3個新的等待事件：

PgStatsDSA	Waiting for stats dynamic shared memory allocator access
PgStatsHash	Waiting for stats shared memory hash table access
PgStatsData	Waiting for shared memory stats data access

隨著 stats collector的所有開銷及維護的消失，其他子程式例如autovacuum要做的工作就更少了。

原文

https://www.percona.com/blog/postgresql-15-stats-collector-gone-whats-new/