【DB吐槽大會】第9期 - PG 大量連接配接寫小事務性能差

背景

1、産品的問題點

• 大量連接配接寫小事務性能差

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

• PG判定事務可見性依賴事務快照, 結構為:ProcArray, 事務啟動時、RC事務隔離級别的Statement執行開始時都要加ProcArray共享鎖, 寫操作的事務結束時需要加ProcArray排他鎖. 高并發寫操作發生時容易産生ProcArray排他鎖沖突. 雖然procarray是有hash分區每次隻鎖映射的分區來降低排他鎖沖突, 但是連接配接過多的情況下沖突依舊明顯.

3、這個問題将影響哪些行業以及業務場景

• 讀寫頻繁、高并發(大量連接配接, 通常指超過5000個連接配接)小事務的業務. 例如2C的SaaS類場景.

4、會導緻什麼問題?

• 高并發寫操作發生時容易産生ProcArray排他鎖沖突. 性能下降. 上萬連接配接的高并發寫操作性能可能降低到1000 tps以内.

5、業務上應該如何避免這個坑

• 使用連接配接池, 降低總連接配接數.
• 如果應用程式本身不具備連接配接池的能力, 使用pgbouncer這類中間連接配接池

6、業務上避免這個坑犧牲了什麼, 會引入什麼新的問題

• 管理更加複雜
• pgbouncer引入後, 必須是要statement或transaction level連接配接池, 進而無法使用prepared statement, 導緻query parse,rewrite,plan的開銷增加.

7、資料庫未來産品疊代如何修複這個坑

• 内置線程池
• 對事務快照進行 CSN 或 CTS 改造

• • https://github.com/alibaba/PolarDB-for-PostgreSQL/blob/master/doc/polardb/cts.md

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