第21期吐槽:90%的性能抖动是缺少这个功能造成的！也是DBA害怕开发去线上跑SQL的魔咒
文中参考文档点击阅读原文打开, 同时推荐2个学习环境:
1、懒人Docker镜像, 已打包200+插件:《最好的PostgreSQL学习镜像》
2、有web浏览器就能用的云起实验室: 《免费体验PolarDB开源数据库》
3、PolarDB开源数据库内核、最佳实践等学习图谱: https://www.aliyun.com/database/openpolardb/activity
第21期吐槽:PG 没有持久化Shared Buffer
1、产品的问题点
PG 没有持久化Shared Buffer
2、问题点背后涉及的技术原理
PG Shared Buffer采用1个大池子(除了ring buffer以外), 数据访问和修改需要先将数据写入shared buffer, 当内存不够时使用LRU算法淘汰shared buffer中的page.
pG也设计了ring buffer来降低扫描大量数据的任务（例如大表全表扫描，建索引，垃圾回收，analyze等任务）引起的热表buffer被挤出的概率。但它有边界，我没记错的话全表扫描时表大小要超过shared buffer 四分之一才会触发使用ring buffer具体见代码。
3、这个问题将影响哪些行业以及业务场景
OLTP类业务
4、会导致什么问题?
一些突发的大的查询可能将热数据挤出shared buffer, 从而影响热数据相关SQL的响应速度, 导致性能抖动, 体验下降.
- 开发出于调试或紧急事件需要线上跑SQL, 可能把热表挤出去。导致高峰期性能抖动。
5、业务上应该如何避免这个坑
暂时没有好的解决方案, 只能在发布前做好严格的测试再发布, 避免突发大查询
使用pgfincore插件 ( 参考: 《TOAST table with pgfincore》 ), 通过修改open file的flag来将某些热表尽量保存在os层Page cache里. 使用这种方法有前置依赖同时也不保险并且会有一定的副作用.
前置依赖: 有os page cache的文件系统, page cache够大
不保险: 当系统内存不足时, page cache依旧有可被挤出的可能
副作用: page cache+shared buffer 导致 double cache.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
成本较高, 无法完全避免
人为的大查询无法避免, 通过管理手段可以减少风险, 但是无法避免.
7、数据库未来产品迭代如何修复这个坑
增加几类独立的shared buffer池, 可以将明知的热的表永久保留在池子内, 避免干扰. 增加DBA的可管理手段.
本期彩蛋-运营妹纸一枚
以下信息已经征得本人同意发布，有意的企业可以直接联系勾搭。
姓名：李佳芸
电话：19857104289（微信同号）
个人简介：5年技术社区运营经验，有仅有社区初期建设的经验，并且有一定行业 KOL 、媒体资源积累，熟悉主流媒体运营机制，如公众号、知乎、掘金、CSDN.....
策划过多场直播活动，在 CQ 期间，通过优化主题及直播渠道，将直播数据从单场 200，增长到平均每场 1K+，单场累计播放 4K+；
善于内外部资源整合，曾在 OceanBase 负责社区内容建设，在职期间通过制定内容激励机制，拉通技术专家及外部用户产出过 100 多篇文章，并沉淀出 5 大技术专题。
文章中的参考文档请点击阅读原文获得.
欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.
近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号: