背景

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的可管理手段.