【DB吐槽大會】第40期 - PG 缺少qps計數器

背景

1、産品的問題點

• PG 缺少qps計數器

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

• qps: 包括insert, update, select, delete.

• • 通常需要支援 nestloop、top選擇(由于function 有内置sql的存在).

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

• 通用

4、會導緻什麼問題?

• 無法統計qps, 缺少展現業務吞吐的名額. 其他名額無法直接反映業務吞吐.

• • CPU負載、IOPS無法展現業務名額. 不能說負載高業務吞吐就高(有可能是SQL沒有優化導緻)
  • TPS可以, 但是隻算commit、rollback兩個次元, 并且不包括隻讀的事務, 展現次元較弱. (純粹的查詢無法通過tps反映)
  • 索引掃描了多少條目、表掃描了多少行數、插入行數、删除行數、更新行數.

《PostgreSQL tuples_returned , tuples_fetched 說明》

blks_read                | bigint                   |           |          |   
 blks_hit                 | bigint                   |           |          |   
 tup_returned             | bigint                   |           |          |   
 tup_fetched              | bigint                   |           |          |   
 tup_inserted             | bigint                   |           |          |   
 tup_updated              | bigint                   |           |          |   
 tup_deleted        

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

• 通過 pg_stat_statements 的calls進行計算, 但是無法完美計算qps, 因為記錄的sql容量有限(參數控制)

• • 《PostgreSQL 實時健康監控 大屏 - 低頻名額 - 珍藏級》
  • 《PostgreSQL 實時健康監控 大屏 - 高頻名額(伺服器) - 珍藏級》
  • 《PostgreSQL 實時健康監控 大屏 - 高頻名額 - 珍藏級》

• 或者自己寫個插件,改一下pg_stat_statement也能支援qps.

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

• qps監控名額的擷取非常麻煩, 而且不準确, 而且可能重複統計, 例如function和sql. 同時區分 insert,update,delete,select 需要做文本比對, 有性能損耗.

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

• 建議核心層支援qps名額. 在pg_stat_database中支援insert,update,delete,select各項名額.

• • 支援到database特别有意義, 因為很多saas類或者dbaas類業務每個database都對應一個獨立的客戶, 能反應更加精準意義的業務名額, 有業務價值的功能就是好功能.

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