为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。
- 【TiDB 版本】:tidb4.0
- 【问题描述】:集群大量报警tidb_tikvclient_backoff_seconds_count
查看tikv的日志有很多Locked的Warn
[2020/07/31 16:06:34.302 +09:00] [WARN] [endpoint.rs:527] [error-response] [err=“Key is locked (will clean up) primary_lock: 74800000000000024D5F6980000000000000020391DA3DD465CD2000040000000000000000040000000000000000040000000000000001017531323338313038FF3630363231323332FF3934373200000000FB0380000000042D012A lock_version: 418428798708482050 key: 74800000000000024D5F6980000000000000020391DA3DD465CD2000040000000000000000040000000000000000040000000000000002017531323338313038FF3630363231323332FF3934373200000000FB0380000000042D012A lock_ttl: 3001 txn_size: 2”]
从集群dash查看慢查询,发现很多超过3s的insert,同样类型的insert语句耗时高低不同
查看promethus监控
若提问为
性能优化、故障排查类问题,请下载
脚本运行。终端输出打印结果,请
务必全选并复制粘贴上传。
看慢查询日志,sql的耗时主要集中在Prewrite 阶段耗时和Commit 重试等待耗时。这个是因为锁有冲突导致的锁等么?
1 个赞
qizheng
(qizheng)
4
这条日志对于 tikv 来说是正常的,insert 时遇到 lock 会打印该日志,并将 err 返回给 tidb,tidb 会尝试 resolve lock 并 backoff 重试,重试成功后报错不会返回给客户端。
对应的 TiDB 监控体现在 KV Errors 相关面板,关注 KV Retry Duration 的延迟和 KV Backoff OPS 中的 txnlock 是否过高,此外 slow query 日志详细信息也包括 backoff type 类型以及 backoff 的时间占比。
这类冲突出现的原因通常是业务并发写入,建议先检查业务逻辑,可以通过 tidb-ctl 解析 primary_lock 信息,确认冲突的表和索引;另外也可能是 tikv 写入性能较差,提交过程缓慢,更容易遇到锁冲突,需要优化写性能。
从监控面板来看txnlock的值还是挺高的。kv写入的ops并不是很高
qizheng
(qizheng)
10
从上面 slow query duration 看,主要是 prewrite 阶段耗时较高,具体表现在 Commit 过程重试等待耗时上;监控中 KV Cmd Duration 操作比较快,说明 TiKV 性能并不慢,主要是由于 txnlock 的 backoff Duration 较高导致。
HI,
txnlock 的 backoff Duration 较高这两个指标除了业务上写逻辑的review。tikv和tidb配置方面有什么可以调整优化的点么。
来了老弟
12
如果考虑继续使用乐观事务,建议从业务入手,将大事务拆分成小事务运行,batch 在 100 - 500 之间即可
可以反馈下以下监控项,这边在判断下
来了老弟
16
yilong
(yi888long)
19
这个指标并不是很高,可以看下业务侧是否并发写入较多,多谢。