【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信息, 堵塞信息等便于分析.