KingbaseES V8R6等待事件之 lwlock: CSNLogControlLock-CSDN博客

本文链接：https://blog.csdn.net/lyu1026/article/details/140727984

一、原理

CSN日志是数据库中用于记录事务提交顺序和事务状态的重要日志，为了解决高并发场景下获取快照时的性能瓶颈，引入CSN机制。CSN机制通过为每个非只读事务分配一个XID(事务号)，并在事务提交时推进CSN，同时保存CSN与XID的映射关系在CSNLog中。
CSNLogControlLock等待事件通常表示某会话需要读取或写入某个事务的CSNlog时，首先需要获取这个LWLOCK锁，即同一时间只允许一个事务访问CSNLOG,通过这种锁机制，数据库能够确保在并发环境中对CSNLOG的一致而不会出现访问冲突，那么其他事务可能会遇到CSNLogControlLock等待事件。
对于确保数据库的一致性和可恢复性至关重要。总而言之，CSNLogControlLock等待事件通常表示某个会话正在等待获取对CSN日志的访问权限。

查看等待事件的语句：

select wait_event ,datname,pid,state,query,wait_event_type, count(*) from sys_stat_activity group by wait_event,wait_event_type,datname,query, pid,state order by count(*);

二、发生原因

CSNLogControlLock等待事件的发生可能由以下原因引起：
高并发事务：当数据库中存在大量并发执行的事务时，对CSN日志的访问竞争会加剧，导致某些会话需要等待其他会话释放对CSN日志的锁。
长时间运行的事务：某些长时间运行的事务可能会持续持有对CSN日志的锁，导致其他需要访问CSN日志的会话被阻塞，长事务可能由慢sql引起。
资源争用：除了对CSN日志的访问竞争外，其他资源(如CPU、内存、磁盘I/O等)的争用也可能导致CSNLogControlLock等待事件的发生。

三、解决方法

针对CSNLogControlLock等待事件，可以采取以下解决方法：
优化sql，降低并发度：通过优化慢sql，降低事务的复杂度和并发度方式降低等待事件出现概率，通过连接池管理减少长时间运行的事务等方式来优化事务的执行时间，从而减少对CSN日志的访问竞争。
监控和诊断：使用数据库管理系统提供的监控和诊断工具(如KWR,KDDM报告)来监控CSNLogControlLock等待事件的情况，并通过分析相关数据和日志来确定问题的根本原因。
升级硬件：如果资源争用是导致CSNLogControlLock等待事件的主要原因之一，可以考虑升级硬件(如增加CPU核数、扩大内存容量、提高磁盘I/O性能等)来提高数据库的整体性能。

四、具体案例

某保险用户数据库管理系统在运行过程中出现了大量CSNLogControlLock等待事件，并且该等待事件持续存在时间较长，导致应用运行缓慢，卡顿。
据了解，有关sql单独执行不慢，但在程序里执行很慢。由于业务系统复杂度特性，往往一段时间内集成了大量复杂sql，当这些sql同时运行往往会发生更为复杂的情况，例如业务的逻辑，并发度设置不合理，我们会发现常见的数据库等待事件，
然而等待事件恰恰保证数据一致性等数据安全特性而实现的应用效率最大化的功能，方便排查数据库整体性能状况。
根据等待事件原理，经过分析发现，该等待事件主要由高并发事务和慢sql引起，现场不方便开启收集kwr报告功能，我们只能从监控中看到慢sql最快执行时间5秒，最慢一小时之多。
根据等待事件原理解决此问题的方法是，降低应用并发，优化慢sql以便提高sql执行效率，此后应用反馈正常，未发生异常等待。
通过以上措施的实施，CSNLogControlLock等待事件得到了有效的缓解，数据库的性能得到了显著提升。
建议：
根据业务系统实时变更这个特性，需要实时监控慢sql。
强烈建议开启kwr报告，以便出现等待事件等问题时可以通过收集间隔快照方式详细分析应用卡顿原因。