TIKV锁引起的性能问题

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【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 重试等待耗时。这个是因为锁有冲突导致的锁等么?

这条日志对于 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并不是很高

从上面 slow query duration 看,主要是 prewrite 阶段耗时较高,具体表现在 Commit 过程重试等待耗时上;监控中 KV Cmd Duration 操作比较快,说明 TiKV 性能并不慢,主要是由于 txnlock 的 backoff Duration 较高导致。

HI,
txnlock 的 backoff Duration 较高这两个指标除了业务上写逻辑的review。tikv和tidb配置方面有什么可以调整优化的点么。

如果考虑继续使用乐观事务,建议从业务入手,将大事务拆分成小事务运行,batch 在 100 - 500 之间即可

可以反馈下以下监控项,这边在判断下

看OPS情况感觉这个值并不是很高呀。

HI,这个error是不是很高了

如果不方便提供上面的监控,建议根据此建议修改下事务,

如下文章可以看下是否有帮助:
https://book.tidb.io/session4/chapter6/avoid-optimistic-lock-conflicts.html

这个在那个监控页面看呀。PD那个监控面板么

这个指标并不是很高,可以看下业务侧是否并发写入较多,多谢。