【DB吐槽大會】第6期 - PG Double Cache

背景

1、産品的問題點

• OS page cache, buffer pool 雙重緩存, 存在一定的記憶體浪費.

2、問題點背後涉及的技術原理

• PG 的資料的寫操作采用buffer IO接口, 在OS層會産生緩存, 最後由IO子系統合并寫入塊裝置. 讀操作與之類似.

3、這個問題将影響哪些行業以及業務場景

• 所有場景

4、會導緻什麼問題?

• 記憶體浪費.
• 如果OS層的bg write排程沒有配置得當會導緻IO hang或者大型IO等問題.
• 無法發揮最大的IO裝置帶寬潛能.
• 好處也有一丢丢: OS層的IO合并可以減少總的IO次數.
• OS有一層cache, 當資料庫重新開機時可以緩沖一下, 不會直接全部打到IO塊裝置上.
• 當使用IO延遲較高的塊裝置時, buffer IO的性能影響較小(buffer write場景).

5、業務上應該如何避免這個坑

• 基本無解.
• 使用大一點點的shared buffer并且使用huge page配置.
• 使用pgfincore插件, 将fd改成adviceFlag = POSIX_FADV_DONTNEED, 會盡快淘汰對應page, 但是并不代表不過os cache層.

6、業務上避免這個坑犧牲了什麼, 會引入什麼新的問題

• 無法避免

7、資料庫未來産品疊代如何修複這個坑

• 改造核心, 使用計算存儲分離架構, 類似PolarDB, 使用DIO解決

https://github.com/digoal/blog/blob/master/202108/20210828_06.md#postgresql-%E8%AE%B8%E6%84%BF%E9%93%BE%E6%8E%A5 https://github.com/digoal/blog/issues/76