tidb慢日志出现较多Backoff_time很大

版本 : 2.1
tidb慢日志出现较多Backoff_time很大的情况(有一部分是Wait_time较大),但是实际该sql的执行计划是很好的,而且查看监控也没发现什么异常,所以想请教一下这个问题应该怎么排查。





经过查看tidb监控, KV Errors 下 Lock Resolve OPS 面板中的 not_expired/resolve 监控项以及 KV Backoff OPS 面板中的 txnLockFast 监控项都没有明显的上升趋势。

tikv监控的error部分也没严重错误

查看pd监控也没有热点我问题

region也相对稳定

CPU也没什么压力

QPS情况如下

1 Like

升级一下版本吧,2.1的版本有点太老了。

Backoff_time:表示语句遇到需要重试的错误时在重试前等待的时间。常见的需要重试的错误有以下几种:遇到了 lock、Region 分裂、tikv server is busy。

参考地址:
https://docs.pingcap.com/zh/tidb/stable/identify-slow-queries#字段含义说明

从tikv的日志能看到很多lock的信息,这个该如何排查呢,请教一下排查思路


锁冲突大多数都是由于多个线程并发执行时,有重复数据导致的(主键重复)。

可以把审计日志打开后,通过下面关键字过滤汇总一下。看看哪个表的冲突比较多,针对性的优化。
grep “Write conflict” tidb.log

2.1 版本好像还有读写冲突,这个需要具体看一下,这块我了解比较少。

谢谢,社区版本好像没审计功能,就比较尴尬了

还有一个疑问,针对这种问题,升级到高版本能解决?

升级到高的版本,比如3.0.8 之后支持悲观锁

目前2.X的版本,默认的是乐观锁, 升级对于这个锁冲突的问题,有点效果(乐观 => 悲观)

但是如果能从业务的角度去解决这个冲突,效果会更好

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。