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