为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
- 【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
这个指标并不是很高，可以看下业务侧是否并发写入较多，多谢。
