夜里tidb节点CPU使用率突然暴增，应该如何排查
可以先看下集群 QPS 是否有增加，如果 qps 没有变化，但是 CPU 上升了，可以看下慢日志以及慢日志中执行计划情况，看下是否是执行计划走错了
方便的话可以上传一下完整 的监控，我们看下 TiKV-Details/PD/TiDB/Overview
1）使用 chrome 浏览器，安装“Full Page Screen Capture”插件：
https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl
2）展开grafana 监控的 “cluster-name-overview” 的所有 dashboard （先按 d 再按 E 可将所有 Rows 的 Panels 打开，需等待一段时间待页面加载完成）
3）使用插件导出 pdf
链接:https://pan.baidu.com/s/1gQWXxgnBARYEBxWrHvIZRQ 密码:74yf
已使用截屏软件上传，希望官方爸爸尽快帮我们分析原因
看监控的QPS指标并无猛烈增加，趋势平稳
通过 tikv-details → grpc 监控看档当时 的 kv_batch_get_command 以及 kv_scan 的请求当时有大量上涨
另外看当时 replace 的请求也上升了
麻烦确认 一下：
- replace 请求上升的原因
- 另外有确认过慢日志中的执行计划吗，有执行计划走错的情况么
replace应该是跟mysql的实时同步导致的，我们现在用的是syncer组件做的
我的监控条件取得两天的做得对比，昨天夜里和今天夜里replace的量应该是差不多的
我们刚刚发现grpc出了很多看门狗报错，有可能是这个引起的么
kv_batch_get_command
kv_scan
这俩不太明白是啥
但是从时间上看从凌晨两点开始CPU占用率就开始上升了，看门狗报错是从4点以后开始的
一直到上午10点多好像tidb节点自己重启了，cpu的占用率才下来
昨天重启过之后夜里没再出现tidb节点CPU过高的情况
不过对比了下升级前后的指标，发现3.0.7升级到4.0.2之后Tidb的Duration和Transaction Duration指标普遍升高了
根据上面的提示，检查下对应时间点 slow log 中是否存在 sql 执行计划走错的情况吧
如果慢日志中输出了执行计划，可以直接查看执行计划。用 select tidb_decode_plan(‘xxx…’) 语句可以解析出具体的执行计划。
kv scan 指的是 tikv范围扫描的 kv 增多。
额～意思是不是网络原因么
我们大部分是AP应用场景的
这个怎么能看出来执行计划是不是走错了呢
screencapture-120-92-213-119-dashboard-2020-07-13-11_12_02.pdf (561.3 KB)
screencapture-120-92-213-119-dashboard-2020-07-13-11_14_16.pdf (876.2 KB)
这是前两个的执行明细，帮我们分析一下吧
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。