【DB吐槽大會】第21期 - PG 沒有持久化Shared Buffer

背景

1、産品的問題點

• PG 沒有持久化Shared Buffer

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

• PG Shared Buffer采用1個大池子(除了ring buffer以外), 資料通路和修改需要先将資料寫入shared buffer, 當記憶體不夠時使用LRU算法淘汰shared buffer中的page.

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

• OLTP類業務

4、會導緻什麼問題?

• 一些突發的大的查詢可能将熱資料擠出shared buffer, 進而影響熱資料相關SQL的響應速度, 導緻性能抖動, 體驗下降.

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

• 暫時沒有好的解決方案, 隻能在釋出前做好嚴格的測試再釋出, 避免突發大查詢

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

• 成本較高, 無法完全避免
• 人為的大查詢無法避免, 通過管理手段可以減少風險, 但是無法避免.

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

• 增加幾類獨立的shared buffer池, 可以将明知的熱的表永久保留在池子内, 避免幹擾. 增加DBA的可管理手段.

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