背景：
一段运行很久的TiDB集群，昨日突然出现耗时翻倍的情况。
再此之前我们已知存在少量读写冲突的情况，并对上游的消费做了分流来规避一部分冲突。
个人排查和处理过程：
- 在SQL类型耗时中，可以看出主要为写请求，insert和update类型耗时增加严重（400ms->1-3s）。 并且相对应TiKV的commit和prewrite耗时同样增加。
- 在KV Request Duration 999 by store中发现，部分TiKV节点耗时偏高，重启后Leader均衡完耗时继续升高。
- 锁资源上发现tikvLockFast数量上升，但也可能是因为写请求处理缓慢导致锁等待更严重
- 线程CPU资源上看起来还没到达瓶颈，系统资源（CPU、IO）也未达到瓶颈。
- 已知存在热点问题，核心表使用了auto_increment
综上所述，我没有找到部分TiKV耗时突然升高的原因，在这请求各位帮助。需要我提供哪些数据支撑来辅助分析？
环境
版本：3.0.11
yilong
(yi888long)
2
如果主要是写请求麻烦上传 监控信息 over-view，tidb ， detail-tikv 问题发生时间段的监控，多谢。
(1)、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl
(2)、鼠标焦点置于 Dashboard 上，按 ?可显示所有快捷键，先按 d 再按 E 可将所有 Rows 的 Panels 打开，需等待一段时间待页面加载完成。
(3)、使用这个 full-page-screen-capture 插件进行截屏保存
过程中Tikv耗时抖动了几次，目前平均值还是处于高于历史的一个水平，我就截当前的时间吧。
OverView
Tidb
Tikv-detail
感谢回复！
因为Region过多的原因，Raft store的pool size 之前有修改过，store-pool-size = 6
同时目前也有开启静默Region的打算。 但是在raftCpu未打满的情况下， 目前这种耗时还有其他原因吗？
yilong
(yi888long)
6
麻烦上传觉得耗时突然增加的那段时间可以对比看一下的监控，最好是比平常的这种耗时有一个明显的增加，这样方便对比，多谢。
主要都慢在了 store4，单选 store 4 instance 看下 tikv details 面版
这些时间这个 tikv 都有抖动
主要是因为 kvdb 的 write duration 有都抖动
抖动原因看不太出来，建议升级到最新的 3.0 版本，并设置 perf-level = 4 看一下
