PostgreSQL死锁问题（Deadlock found when trying to get lock）如何快速定位原因及解决

目录

前言

一. PostgreSQL锁问题

1.常见的锁相关问题

2.锁问题分析的难点

二.锁分析案例

三. 还原PG死锁问题形成过程

四. 其他锁场景如何快速定位

1.锁等待可视化分析

2.未提交事务可视化

3.长事务可视化

---

前言

PG大象和MySQL海豚到底谁跑的更快，一直都是业界热点，但是一旦被锁住，谁都跑不了，以下场景你是否似曾相识？

• 应用服务没有发布任何代码变更，但平时很快的接口突然响应变慢又抖动？

• 比较顺滑的功能页面突然打不开了，浏览器一直在转圈圈？

这些问题的出现大多是由于锁引发的性能问题，就如同悬在头顶的利剑，随时可能引发灾难！

一. PostgreSQL锁问题

1.常见的锁相关问题

• 锁等待：大量时间用于等待锁资源，严重影响数据库性能。

• 死锁：造成业务异常或损失。

• 未提交事务与长事务：会长时间持有锁资源，增加锁问题发生的概率。

2.锁问题分析的难点

• 锁机制的复杂性：PostgreSQL的锁机制是相当复杂的，涉及多种类型的锁，如行级锁、表级锁、页级锁等，不同的锁级别又会影响并发性和性能。这使得理解和管理锁变得复杂，尤其是在大型或高并发的数据库系统中。

• 并发事务复杂性：锁问题通常发生在多个并发事务之间，这增加了定位问题的复杂性。理解并发事务之间的相互依赖关系和锁竞争情况对于分析锁相关问题至关重要。

• 死锁链的复杂性：可能存在多个死锁链，进一步增加梳理与分析的难度。

• 难以重现和调试：有些锁问题可能是偶发性的或难以重现的，这使得调试和解决问题变得更加困难。特别是在生产环境中，由于无法简单地重现问题，需要更加谨慎地分析和调试。

• 日志分析的挑战：虽然PostgreSQL会记录死锁事件，但死锁日志难以阅读和梳理。需要详细分析日志以了解死锁发生时的上下文信息、涉及的事务和锁等待情况。

• 监控和诊断工具的局限：尽管PostgreSQL提供了一些系统视图和功能来监控锁活动，但在复杂的生产环境中，很难快速的组合利用好这些工具分析出结果。

二.锁分析案例

此处以死锁问题为例：

a）锁问题识别，在该阶段多通过业务服务异常日志或者通过PostgreSQL数据库监控发现存在死锁事件。

b）查看PostgreSQL日志可以查看到进一步的死锁信息，如下图所示，死锁日志展示造成死锁的两个事务，以及等锁的两条SQL，到此环节无更多信息推断出这两个事务是如何形成的死锁环。

2024-05-26 21:59:20.868 EDT [14761] ERROR:  deadlock detected
2024-05-26 21:59:20.868 EDT [14761] DETAIL:  Process 14761 waits for ShareLock on transaction 36986; blocked by process 14762.
        Process 14762 waits for ShareLock on transaction 36985; blocked by process 14761.
        Process 14761: update people set age=33 where id=1;
        Process 14762: update people set age=23 where id=2;
2024-05-26 21:59:20.868 EDT [14761] HINT:  See server log for query details.
2024-05-26 21:59:20.868 EDT [14761] CONTEXT:  while updating tuple (1090,20) in relation "people"
2024-05-26 21:59:20.868 EDT [14761] STATEMENT:  update p