【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解决