【DB吐槽大會】第64期 - PG 裡面的某些單核瓶頸

背景

1、産品的問題點

• PG 裡面的某些單核瓶頸

2、問題點背後涉及的技術原理

• 雖然PG已經支援并行計算, 大多數的SQL支援通過并行計算加速, 使得PG可以支撐OLAP類業務. 但是還存在一些單核場景.

• • WAL writer
  • vacuum 單表/單分區時
  • checkpointer
  • 崩潰recovery時

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

https://github.com/digoal/blog/blob/master/202109/20210930_02.md#postgresql-%E8%AE%B8%E6%84%BF%E9%93%BE%E6%8E%A5 https://github.com/digoal/blog/issues/76