最近工作壓力很大，同時本着對閱讀者負責的態度，原來是一天一篇的速度，必然是支持不下去了，所以以後會提高文字的質量，降低數量，對得起自己也對得起閱讀的人。未來說不好，可能一週2篇，另外爭取做到沒有錯別字。本篇爲之前的存貨。
懂得postgresql 數據庫原理的都知道 vacuum 的重要性，而相關線程中，autovacuum 是重要的，或者說最重要也是當之無愧。
Autovacuum 作爲postgresql 的一個進程一致在工作。
那麼這個autovacuum 在除了進行和他名字一樣的工作之外，他還負責要收集更多關於dead tuple 和膨脹的信息，要對更新表統計信息的表進行分析，以便優化器能夠爲SQL語句選擇最佳執行計劃。
在PG中還有另外一進程 stats collector ，用於跟蹤使用情況和活動信息。這些信息會被autovacuum來進行利用。來更好的進行相關的清理工作。
這兩個功能在 postgresql.conf 中的開關就是
同時在系統進行vacuum的同時，作爲DBA 是希望能進行分析的所以日誌中能進行記錄那是最好的。所以log_autoovacuum_min_duration 可以記錄指定時間超過250毫秒的vacuum 就會被記錄。
那在重啓後，我們能看到的日誌中的記錄就是下面這個樣子。所以Postgresql在日誌方面的記錄是很全面的，這相對於某些數據庫（SQL SERVER 和 MYSQL）要好的太多了。
所以給POSTGRESQL 日誌配一個好的快速的空間在大型頻繁的系統是有必要的。
下面接着的問題是，到底什麼樣的表會被進行autovacuum，或者是備選對象。
實際死的tuple >= autovacuum_vacuum_scale_factor * number of tuples + autovacuum_vacuum_threshold
上面的公式就是表在插入，更新，刪除後會被選入到autovacuum中的方法。下面的參數們就是觸發分析或進行autovacuum的選擇項
例如上面的操作 例如一個表中的行數是1000行（1000*0.2）+50 = 250行，當這個表現在的死行超過250行，就要觸發vacuum了。所以調整這個參數是很重要的，另外如果有大表的情況下，你會發現你清理dead T 的速度是越來越慢，那就的對有些大表進行自定義。
怎麼定義？首先先確認經常有處理不完的dead tuple 是那些表，
SELECT n_tup_ins as "inserts",n_tup_upd as "updates",n_tup_del as "deletes", n_live_tup as "live_tuples", n_dead_tup as "dead_tuples"
FROM pg_stat_user_tables
通過手動的方式，可以調整這兩個參數來達到針對這個表進行更頻繁或者更不頻繁的vacuum的方法。
在講完這些後，還有一個問題，就是清理表的vacuum 的線程有沒有數量的限制。autovacuum_max_workers 就是控制工作線程的數量的參數，如果你有四個數據庫，則另一個數據庫就要等待，到下一個週期才能輪上這個數據庫的表進行操作。所以可以適當的調整一下這個參數，如果你一個cluster中的數據庫比較多的情況下。
說到這裏，目前還有一個問題需要考慮，就是業務繁忙時期到底要不要進行AUTOVACUUM, 是不是會在業務繁忙的時候，雪上加霜，對於性能更不利。
自動真空從磁盤讀取一個表的8KB(默認的block_size)頁，並修改/寫入包含死元組的頁。這涉及讀和寫IO。因此，這可能是一個IO密集型操作，在事務高峯期間，在一個包含許多死元組的巨大表上運行一個自動真空，是否是一件好事，所以爲了避免這樣的情況，可以在參數中進行配置。
vacuum_cost_page_hit 是你在緩衝中能讀取頁面的cost
vacuum_cost_page_miss 是不在緩衝中讀取的頁面的cost
vacuum_cost_page_dirty 是在頁面中發現dead T 後進行重寫的成本
假如 vacuum_cost_delay = 20 的情況下，一秒是1000毫秒，則會發生50次的vacuum，在默認的情況下 根據時間的定義
下面有一個公式
200 * 50 * 8 = 在buffer 中可以處理的dead T數據量
200/10*50 *8= 在磁盤中可以處理的dead T 的數據量
200/20*50*8 = 在一個週期可以處理的dead T 並改寫的數量
這三個數量是成遞減的分佈的，所以調高autovacuum_max_workers，成本被平均分配給實例中運行的所有autovacuum進程的autovacuum數量。因此，增加autovacuum um_max_workers可能會延遲當前運行的autovacuum workers的自動真空執行。增加autovacuum um_vacuum um_cost_limit可能會導致IO瓶頸。
當然這些參數也是可以針對表進行特殊設置的。所以到此autovacuum 的調整絕對屬於一個高智商的數學和判斷題。
共享文件持續更新中，如有需要入羣自取
