【DB吐槽大會】第49期 - PG 不支援列印慢SQL鎖等待資訊

背景

1、産品的問題點

• PG 不支援列印慢SQL鎖等待資訊

• • 實際上

    log_min_duration, auto_explain, pg_stat_statements

    都沒有統計SQL的鎖等待時長.

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

• log_min_duration

  , 執行時長超過這個值的SQL會被列印到日志中, 但是日志中并不會記錄這條SQL的鎖等待耗時.

• auto_explain

  插件可以用于列印執行時間超過

  auto_explain.log_min_duration

  時長的SQL, 包括其執行計劃, NODE的執行時間等. 但是鎖等待的耗時算在整個SQL,不會單獨統計.

• log_lock_waits

  會記錄超出鎖等待時長超過

  deadlock_timeout

  的會話和事務, 但是不列印sql, 而且每隔

  deadlock_timeout

  時間列印一條, 很難彙總統計.

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

• 通用

4、會導緻什麼問題?

• 分析因為鎖等待導緻的問題非常麻煩, 而且鎖等待通常是業務邏輯導緻的問題, 這樣需要引入開發者一起來進行分析下. 分析問題的門檻高.

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

• 暫無很好的解決方案, 隻能經常采集

  pg_locks, pg_stat_activity

  的動态視圖資訊, 進行等待統計.

• • 《PostgreSQL 活躍會話曆史記錄插件 - pgsentinel 類似performance insight \ Oracle ASH Active Session History》
  • 《PostgreSQL Oracle 相容性之 - performance insight - AWS performance insight 理念與實作解讀 - 珍藏級》

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

• 管理複雜度增加

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

• 希望核心層面在

  log_min_duration

  和

  auto_explain

  記錄的SQL中記錄鎖等待的時長,
• 同時希望

  log_lock_waits

  可以把同一個請求到鎖等待日志彙總到一起, 包括SQL資訊, 堵塞資訊等便于分析.