digoal
2021-09-30
PostgreSQL , 单核 , 瓶颈 , vacuum , wal , checkpoint
1、产品的问题点
- PG 里面的某些单核瓶颈
2、问题点背后涉及的技术原理
- 虽然PG已经支持并行计算, 大多数的SQL支持通过并行计算加速, 使得PG可以支撑OLAP类业务. 但是还存在一些单核场景.
- WAL writer
- vacuum 单表/单分区时
- checkpointer
- 崩溃recovery时
- bgwriter
3、这个问题将影响哪些行业以及业务场景
- 写压力较大的场景
- 表比较大而且这个表的更新并发较高的场景, 例如互联网业务
- ssd云盘使用网络通信, 相比本地盘存在先天缺陷, 虽然带宽大, 但是每次IO的延迟较高. 所以小IO或离散IO的场景(特别是数据库): 单线程打不满IO.
4、会导致什么问题?
- 写压力特别大的场景, 可能有两个性能瓶颈, datalbock extend exclusive lock, 或者 wal insert exclusive lock.
- 表比较大, 而且更新并发高时, 可能导致vacuum赶不上产生垃圾的速度, 产生恶性表膨胀.
- shared buffer配置较大而且脏页较多时, checkpoint 周期可能会很长.
- 如果检查点周期很长, 崩溃恢复过程中需要恢复的WAL文件数可能较多, 从而导致恢复时间漫长.
5、业务上应该如何避免这个坑
- 拆库
- 拆表或使用分区表, 解决vacuum 单表/单分区串行问题.
- 配置更豪华的SSD存储, 一定程度缓解检查点慢或者恢复慢点问题
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 需要调整业务, 可能涉及业务代码的修改.
- 分区表会引入一定的性能问题. (PG大版本有改观, 性能影响几乎可以忽略不计, 一定要用大版本).
7、数据库未来产品迭代如何修复这个坑
- 希望内核层面可以支持更多并行化的后台进程任务
- 采用 wal 分区设计、减少锁冲突、同时支持更多的并行insert
- 支持vacuum 单表/单分区/单索引内的并行(目前支持单表的多个索引的并行)
- 支持并行的checkpoint, 支持并行的recovery
您的愿望将传达给PG kernel hacker、数据库厂商等, 帮助提高数据库产品质量和功能, 说不定下一个PG版本就有您提出的功能点. 针对非常好的提议，奖励限量版PG文化衫、纪念品、贴纸、PG热门书籍等，奖品丰富，快来许愿。开不开森.
