TiKV多次重启，TiDB节点无法使用

[Renne (Hacker Ckfy Z Pda)]

• 【TiDB 版本】：4.0.0
• 【问题描述】：其中一台KV最先报警，查看系统日志发现发生OOM
  
  

查看该TiKV日志，发现最先报警的tikv故障期间一共重启3-5次，其中人为重启2次（32分，54分左右）

另两台：

查看TiKV日志，故障点前有大量Keepalive watchdog fired. Closing transport.告警，后续有大量RaftClient send fail告警，大致如下：

grafana监控大致如下：

查看dashboard中慢查询统计，故障时间段内只有一个analyze大致吻合：

想请教下老师这个analyze花了20分钟正常吗（表大小2700W，analyze开始时间大概在上述报警后17分钟，参考图里tidashboard的统计）

另外TiDB中暂时没有看到明显的错误：

问题到底如何定位呢？谢谢

[来了老弟]

建议通过 dmesg -T |grep 确认下是否为 oom 问题。
将当前 display 结果反馈下。
https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-map.md#42-tikv-oom

[Renne (Hacker Ckfy Z Pda)]

现在已经确认是TiKV OOM的问题，但是无法定位引起的原因/SQL/操作

[yilong (yi888long)]

既然是 OOM ，请在 dashboard 这里点击下 内存，看看这段时间消耗内存最多的 sql 是什么？

[Renne (Hacker Ckfy Z Pda)]

这是个insert into… select …from的同步SQL，10分钟跑一次，看上去就是这个问题了，但是为何11点集群正常后他执行时间和消耗内存也正常了？

[来了老弟]

使用以下方式给一下 grafana - tikv detail 的完整监控吧，

打开 grafana 监控，先按 d 再按 shift+e 可以打开所有监控项。

(1)、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl

(2)、鼠标焦点置于 Dashboard 上，按 ?可显示所有快捷键，先按 d 再按 E 可将所有 Rows 的 Panels 打开，需等待一段时间待页面加载完成。

(3)、使用这个 full-page-screen-capture 插件进行截屏保存

[Renne (Hacker Ckfy Z Pda)]

因公司保密原因不方便全部截图，

但是从最后一张图可以看到故障发生时2台tikv的leader全没了？这是网络原因吗？

[yilong (yi888long)]

既然是 OOM 就先集中看这些占用内存大的sql吧。 insert into… select …from的同步SQL ，这些 sql 是不是在占用内存大的时候，有 select 全表？ 其余时刻有卡where 条件比较小？ 麻烦先从业务上排查下这些sql吧。

[Renne (Hacker Ckfy Z Pda)]

好的 谢谢

[来了老弟]

已经确定是慢语句的问题了吗