第6期吐槽:2024了还没用上DIO，不浪费内存才怪呢！
文中参考文档点击阅读原文打开, 同时推荐2个学习环境:
1、懒人Docker镜像, 已打包200+插件:《最好的PostgreSQL学习镜像》
2、有web浏览器就能用的云起实验室: 《免费体验PolarDB开源数据库》
3、PolarDB开源数据库内核、最佳实践等学习图谱: https://www.aliyun.com/database/openpolardb/activity
第6期吐槽:怪不得浪费内存,2024了还没用上DIO
double cache的问题可能快解决了: pg 16开始支持io_direct. 《PostgreSQL 16 preview - Add io_direct setting (developer-only) - 终于想好好搞shared buffer管理了?》
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解决
文章中的参考文档请点击阅读原文获得.
欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.
近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号: