【 TiDB 版本】5.4.1
【遇到的问题】中午15点左右，tidb查询突然变慢，dm也不同步，后面发现其中一个tikv节点cpu很高（一共7个tikv节点），停掉这个tikv节点后集群恢复正常。
anafin
(0106)
2
补充下：日志出现比较多 check leader rpc costs too long
1.完整的tikv监控发一下
2. 当时的热力图
3.tikv问题节点的日志
anafin
(0106)
4
tidb-app-TiKV-Details - Grafana.pdf (1.0 MB) 70kvlog.zip (1.7 MB)
分布是kv 监控及故障节点（192.168.10.70）的kv的日志文件（内容太多，已过滤掉INFO级别的日志）
故障持续时间：25日 15:00-17:27，期间做了一轮kv，tiflash，db节点重启均无效果，sql无论查询还是update都很慢（sql 的qps比正常期间少，因为已经转移走了一部分流量），17:27时stop 掉故障节点后机器sql处理恢复正常
看日志，很多key is locked，参考下面帖子吧。
anafin
(0106)
8
这个解析不通为什么stop 这个kv节点后就集群正常了；感觉这个不是根因。
补充下信息：
这个节点的cpu配置比其他kv的更好，故障期间内存正常，磁盘容量不超60%、io使用率下降，io量下降，网络流量下降（我理解这些下降，因为流量下降），异常点：cpu使用率比其他正常的6个kv节点高很多；
看15点的时候，raft的write请求很高。写延迟也增加了。那会儿你们业务有什么变化？
还有机器的io情况有什么变化？
70这台机器的读请求也很高，不均衡。是不是有都热点。
看很多transport full
这个storeid是什么？tikv给他发消息总是发不过去。
看了下上面，是53连不上了吧，看下53是什么情况？
检查一下这个store 1422582 看起来是有问题的。
避免向非健康状态的 TiKV 节点发送请求，以提升可用性。这个是5.4.2，可以适当升级
请问你和上面那个回复说的store_id要怎么查看
pd-ctl store
这里面就有storeid对应的tikv是哪个。
找到这个表了，按照上面的回复，10.52和10.53都有问题？
52\53 是tiflash吗？看起来是因为和他们发消息不通。至于是不是导致cpu骤增的原因，不确定。
