tikv wait_time.snapshot耗时很高

[sgjr]

【 TiDB 使用环境】生产环境
【 TiDB 版本】v4.0.14
【遇到的问题：问题现象及影响】

• 出现大量慢SQL
  
  

  

• 查看tidb日志有大量invalidate current region, because others failed on same store 的日志，指向的是同- 一个TIKV节点
  

  

• 查看TIKV节点日志,都是指向同一个region
  

  

• Tidashboard 热点图
  

  

【资源配置】TiKV 9c/90g * 7

[Billmay表妹 (表妹)]

TiDB 社区搜索

这里有些实践你看看你能不能帮助到你

[tidb菜鸟一只 (小菜一颗)]

dashboard点击sql进入sql详情页面看看语句慢在哪一步

[tug_twf (Hacker Fqg5 Vi Rn)]

prewrite 和lock哈 这些看起来都是被影响的

[tug_twf (Hacker Fqg5 Vi Rn)]

tidb-server.log (466.1 KB)
tidb server 日志指向的都是后端某一个tikv节点
这个是这个tikv的日志
tikv.log (6.1 MB)

[考试没答案 (Ti D Ber P Kfity Gq)]

从日志发现的问题

1. timestamp too slow 。向PD获取大量的事务开始时间戳和结束时间戳。可能大量update语句导致，可以批量提交一定量update。多个update一个事务进行提交

2. 进行大量leader选举。可能是系统繁忙无法发送心跳。网络延迟、不好的情况下可以增加选举时间，减少noleader影响

3.很多apply数据到rocksdb KV 库。 提交很频繁。

总结：从业务角度触发，看看为什么这么多的update。让多个update语句一次性提交

[tug_twf (Hacker Fqg5 Vi Rn)]

嗯嗯 这个是业务控制的 也不好批量更新，再者从当时数据库监控和业务的角度来看，更新并没有多多少

[考试没答案 (Ti D Ber P Kfity Gq)]

也就是说：根本没有大批量update 操作吗 ？？ 其他的DML操作有吗

[考试没答案 (Ti D Ber P Kfity Gq)]

大量的慢SQL。update 这些语句慢 是什么 原因，您 分析结果发出来看下吧

[tug_twf (Hacker Fqg5 Vi Rn)]

update 慢都是再prewrite，我们先升级看看