PG double buffering的最佳化

昨天談了 PG的Double Buffering，這一點是很多詬病PG的人經常提到的問題。不過昨天老白也說了，Double Buffering其實也不是什麼太大的問題，對於絕大多數PG資料庫系統來說，這個問題的負面影響絕對沒有網上的那些文章 說的那麼玄乎，甚 至對於絕大多數資料庫來說，這個問題我們可以 忽略 。不過對於一些超大型的 PG資料庫，比如從Oracle遷移到PG的大型或者超大型資料庫來說， 我們還是需要做一定的最佳化工作的 。雖然採用 buffer ed io 的資料庫在 DB CACHE的最佳化上比繞過緩衝區直接讀寫檔案要複雜一些，但是這個問題並不是不可解決的。透過對作業系統與資料庫引數的一系列最佳化，我們也可以讓P G 資料庫充分享受 B UFFERED IO 的好處，規避 Double   Buffering的缺點。

 

第一點是確保有足夠的記憶體，對於採用 Buffered   IO的資料庫系統來說，越大的記憶體擁有越大的F ILE CACHE 和 D B CACHE ，肯定對資料庫的效能有所幫助。在 X86 時代，記憶體已經不少昂貴的硬體了，因此在配置 P G 伺服器的時候，不要為了省幾個記憶體的錢而讓自己今後的運維陷入左右為難的境地是比較明智的選擇。除了配置較大記憶體的資料庫伺服器硬體之外，關閉 N UMA 是我們要做的第一件事情。關閉 N UMA ，不用管遠端記憶體本地記憶體的成本開銷問題，因為遠端記憶體再慢也比硬碟快得多。在伺服器與作業系統層面均關閉 N UMA ，可以讓實體記憶體被均勻的使用，不會因為一個 N ODE 上分配記憶體過大而導致在實體記憶體尚有很多空閒的時候，出現不必要的換頁。對於這個問題，以前老白髮過的一篇文章《 Postgresql和NUMA》 可以參考。

 

第二是大頁的設定，一定要讓 s hared buffers 使用大頁，對於大型 P G 資料庫來說，這一點十分關鍵，如果不使用大頁，有數千會話的資料庫系統的頁表將消耗大量的記憶體和 C PU 資源。在使用大頁的時候一定要注意，不要使用透明大頁。

 

第三是最佳化 O S 的 V M 相關引數。 vm.swappiness 引數可以設定為 0. min_free_kbytes 要設定為一個合理的值，不要讓 f ile cache 超量使用實體記憶體，讓 O S 存在出現大規模換頁的風險。

 

第四是針對 D B CACHE 的髒塊寫入進行 O S 方面的最佳化，對於較大規模的 s hared buffers ，其髒塊重新整理的每個批次的數量會有所增加，使用 b uffered io 的系統的髒塊是先寫到 F ILE CACH 中的，針對 F ILE CACHE 髒資料後臺落盤的最佳化決定了資料庫系統是否能夠平穩執行，消除寫盤高峰。前兩天老白寫過一篇《從 swappiness說起，談談PG的OS引數最佳化》，裡面對這方面的最佳化調整有了十分明細的描述，這裡我們就不再重複了。透過對檔案系統髒資料寫入以及儲存裝置的一些引數的調整，就可以最佳化P G 資料庫的這方面的問題。

 

第五就是 s hared buffers 的設定策略了，我們可以不按照 P G 官方文件上的要求去限制 s hared buffers 不超過 O S 實體記憶體的 25%，而是可以根據我們應用系統資料的特點來設定足夠打的資料庫緩衝區。只要我們給會話、F ILE CACHE 留下足夠大的記憶體就可以了。

 

第六是 WAL 和 C HECKPOINT 的設定，更大的 S HARED BUFFERS 需要更強大的 W AL 和 C HECKPINT 的支援， P G 的預設配置只能適合於特別小的資料庫系統，這方面的最佳化技巧老白以前發過多篇文章，大家可以參考。《《 PG的檢查點與檢查點最佳化》、《從pg_stat_bgwriter中能看到些什麼？》、《聊聊PG的FULL_PAGE_WRITES》、《資料庫髒塊寫入與WRITE AHEAD LOG》 。

第七是正確的設定 I O 評估類的引數，這些引數對於 P G 的執行計劃評估十分重要。前些天老白也曾經寫過《 IO評估類引數對SQL執行計劃的影響 》，裡面討論了相關的 I O 評估類引數的問題，大家可以參考。

 

似乎看上去很複雜，我只是列出了一些主要的針對 Double   Buffering的最佳化要點，還有一些細小的方面今天因為篇幅關係無法展開討論。不過實際上這些最佳化方案，大多數針對不存在Double   Buffering的資料庫也是需要關注的，因此實際上來說最佳化並不複雜。只要根據業務系統的特點，平衡好D B CACHE 與 F ILE CACHE ，讓 O S 不產生嚴重換頁，資料庫系統就能夠穩定高效能的執行了。當然配置足夠的實體記憶體，會讓運維與最佳化更為簡單一些。花上萬把塊錢能夠解決的事情，肯定比花幾十萬去最佳化划算的多，不過這筆帳有時候我們的領導還真不一定算得清， D BA 在必要的時候還是要提醒一下的。