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

如上篇文章提到，若是出現了autovacuum的問題，那麼這多是個悲傷的故事。怎麼解決？

筆者以爲能夠從以下幾個方面着手去考慮解決問題，能夠避免一些坑。
        1)持續觀察，是否是autovacuum問題一直存在，若是隻是偶爾出現一次，可能不須要那麼慌張。由於頗有多是其餘異常狀況形成的。好比當時正在作大規模數據遷移等操做，這種操做若是是偶發的，大可沒必要在乎。

2) 筆者通常的分析思路是從大到小，好比先檢查外圍的關鍵配置項，若是有必要的話，再去深究postgres autovacuum相關的配置項。由於整體來講，調優和分析問題時要切記捨本逐末。就這個問題而言，咱們知道數據庫的讀寫操做，能夠先分開看，這樣比較容易理解。讀，是從disk讀取到OS(操做系統，如Windows/Linux等) cache,再抓取到postgres cache(buffer)，是這樣一個過程。而寫的操做相反，從postgres cache 先寫到os cache，再最後寫入disk。因此說了那麼多，是想表達，外圍的設置很是關鍵，postgres服務器也應該預留足夠的資源給操做系統（如內存，最好能達到20%，甚至更多一點），若是忽略了大的方面的配置檢查和做業，極可能會使調優工做走向不歸路。

3)如上篇文章提到的，autovacuum相關的配置，有大體12個之多，可是真正在開始調整這些參數時要注意的是，有些參數從個人經驗來看，最好先不要動，好比「autovacumm_max_workers」;其默認值爲3，當某些表dead tuple增多時，特別是佔用了50%以上tuples的時候，能夠先調小參數「autovacuum_vacuum_scale_factor」的值。好比能夠從默認的0.2調整爲0.1，增長vacuum的頻率，可能就能解決問題。autovacumm_max_workers最好先不動，是由於若是動了它，可能會有一些反作用，得不償失，具體會在第4點說明。以前筆者在項目中就遇到了這樣的坑。

4)若是此時vacuum的問題解決以後，發現有些SQL執行仍是很慢，經過監控可能發現SQL執行時間起伏比較大。那麼咱們要知道一點的是，autovacuum過程不僅作了vacuum的動做，其實還作了另一個動做，那就是「Analyze"，通俗來講，這個動做就是爲了完成在tuples更新（磁盤更新）以後，執行計劃也應該相應更新，以求獲得最佳/最優執行計劃等等，也很關鍵。你們能夠經過調整「autovacuum_analyze_scale_factor」或參數「autovacuum_analyze_threshold」,若是對於表記錄過多，如超過10000行，能夠直接考慮調整前一個參數便可。

Autovacuum的問題調優，到這裏告一段落。若是有其餘問題或者項目中遇到奇怪的和autovacuum相關的問題，歡迎留言。

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