postgreSQL之autovacuum性能問題分析(一)

最近筆者在項目中遇到postgreSQL的性能問題，因此計劃在公衆號裏寫一個系列文章去追蹤記錄這些問題以及分析過程或解決方法。

本文主要是關於postgreSQL的autovacuum的問題。可能不少人對postgreSQL中的autovacuum是幹什麼的不是特別清楚。網上其實對其概念有了不少的描述。我本身的理解就是，數據庫經過必定的邏輯判斷對數據庫的一些存儲資源進行自動地回收再利用的行爲就是autovacuum.

自從postgreSQL8.1版本引入這個功能以後，不少狀況下在使用時，是開啓autovacuum的，我也特別贊同開啓這個功能。由於人工去作vacuum操做，很差判斷時機和頻率：若是vacuum不及時，不足夠頻繁會形成dead tuples數據過多，形成表相關update/deletion操做性能降低；若是過於頻繁會形成cpu和磁盤讀寫的繁忙，一樣會形成性能問題。

那麼autovacuum會不會有性能問題呢？答案是：可能。autovacuum是把vacuum的操做的頻率和時機交給數據庫去斷定，按理說，這應該是理想狀態或者最優解了，其實未必。在系統上線時若是針對自身業務，未對autovacuum參數進行調優，使用默認值時極可能是有問題的。那麼怎麼找到相關配置呢？

兩種方式查看postgreSQL相關的配置。

*     postgreSQL安裝目錄下，找到配置文件postgresql.conf

*     能夠經過以下SQL語句在postgresql中直接查看autovacuum相關的配置

select * from pg_settings where name like 'autovacuum%';

通常默認的操做值以下，這裏面主要包括2部分，一部分是vacuum，另一部分是analyze. Analyze也是很是重要的built-in操做，會在後續的文章中詳細介紹。這裏主要講解下經常使用的，比較重要的幾個參數，其中「autovacuum_max_workers」,定義了最大的autovacuum的進程數，默認是3. 也就是說同時能夠操做3個表的vacuum操做; "autovacuum_vacuum_threshold"是針對一些小體量的表而言，若是有一張表常年的體量就是20條數據左右，那麼這張表可能永遠不會被autovacuum考慮在內，由於參數autovacuum_vacuum_threshold設定的默認值爲50(>20); "autovacuum_vacuum_scale_factor",這個參數，會考慮的比較多，針對一些大致量的表，好比有1億行數據，那麼針對參數值爲0.2的時候，若是dead tuples達到2千萬行時，會說明此時須要autovacuum，若是vacuum workers的線程被佔滿，那麼就會排隊。

       那麼怎麼去斷定某個特定的表是否有autovacuum的問題呢？那麼筆者的經驗是首先須要一個多時間節點的觀察。若是都知足以下條件，說明相關表是時候進行清理dead_tuples了。

pg_stat_all_tables.n_dead_tup > (threshold + pg_class.reltuples * scale_factor)

       在以上的表達式中，其中能夠經過表pg_stat_all_tables的n_dead_tup字段,加上relname的條件（即表名），就能夠獲取到特定表的dead tuples的數值；threshold便是postgreSQL中的"autovacuum_vacuum_threshold"參數的值，默認爲 50. pg_class.reltuples能夠附加查詢條件 relname="表名"查詢到表中總tuple數; scale_factor是postgreSQL中的"autovacuum_vacuum_scale_factor"參數的值，默認爲0.2。若是以上不等式成立，那麼說明當前表是須要清理dead tuples的，此時能夠監控postgreSQL當前正在進行的autovacuum是否是有包含當前表，若是沒有，那麼可能就須要對autovacuum進程進行調優了。其次是若是有，可是若是dead tuples一直佔有很大比例，那麼也須要進行關注性能問題。

      下次會講解當遇到了autovacuum的問題，怎麼去解決，須要注意什麼。敬請期待。

      你們也能夠掃描並關注以下公衆號「TimTest」，會有更多性能測試相關內容分享。