集群延时忽然猛增

[peng-xin]

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

• 【TiDB 版本】：5.7.25-TiDB-v4.0.4
• 【问题描述】：集群时延忽然猛增，tiflash出现重启。77节点IO打满，load上千，77节点部署了tikv和tiflash。现象如下
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出打印结果，请务必全选并复制粘贴上传。

[yilong (yi888long)]

1.从监控看 77 的 cpu 到达 100%， 内存使用也几乎耗尽

2. 在dashboard 按照内存和 cpu 继续查看哪些 sql 占用了大量内存或者 cpu ，继续排查下，感觉可能是业务上的某些大sql导致的吧，多谢。

[peng-xin]

监控里面没有大查询，10:50左右三个tidb节点的内存使用量没有异常升高。
dashboard中那段时间也没有异常查询

[yilong (yi888long)]

1. 问题应该是发生在 10:50 左右对吧，能否麻烦查看下这个时间段附近的 tidb.log 和 slow log ，是否有其他大查询，如果有查询没有执行完，有可能是没有记录这个sql的。
2. mem-quota-query 请问配置的多少？

[peng-xin]

1.看了下三个tidb的慢查询日志，都是一些插入或者更新，没有大查询。
2.mem-quota-query是默认值，1073741824

[yilong (yi888long)]

1. 麻烦采集下 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 插件进行截屏保存

2. oom-action 的值是多少？

3. 不只是slow 日志，正常的 tidb.log 日志，在问题发生时间附近是否有信息，多谢。

[peng-xin]

荣老师，您好。日志和监控在百度云里面。
oom-action使用的是默认的log。
链接：https://pan.baidu.com/s/1JUvrlMdguOoME14j0iCLbA
提取码：sllz

[tiancaiamao (Genius)]

SELECT * from data_warehouse.f_mid_bussiness_card_week 这条 5.3min 的看起来挺可疑的
10：53 减 5.3min 差不多 10：48, 跟图上的那个异常出现的时间点差不多，CPU，内存，Coprocessor 在这个时间都有个异常波动

[peng-xin]

这个是limit了1000条:rofl:

确实是这个的问题，我刚重试了一下，直接执行SELECT * FROM data_warehouse.f_mid_business_card_week LIMIT 0, 1000;的时候，3秒多返回；

但是执行explain的时候，就卡死不动了，而且整个集群又瘫痪了

这个表是一个周分区表，从2018年1月1号开始，有100多个分区，添加了tiflash存储

[yilong (yi888long)]

1. 日志麻烦取问题发生前后的时间段，太大了，无法下载，到网盘都下不下来。
   

   

2. 查看监控，问题发生时 10:50 前后，duration 升高，qps 几乎掉底
   

   
   
   
   

3. 查看 store kv cmd 时间很长达到分钟级别，主要是 cop 和batchget
   

   

4. 查看 tikv 监控 77 上的写入都很慢，由于 IO 打满，反馈下 77 的 node_expoter 个 disk performance 监控吧
   

   

[peng-xin]

这个应该是tiflash的问题，在分区表进行limit的时候，执行计划会对每个分区进行扫描。

explain.txt (137.3 KB)
log.zip (706.1 KB)
tiflash.log (5.1 MB)

[yilong (yi888long)]

1. 在和您确认下，执行 select * xx 不会导致问题，反而执行 explian sql ， 不是 explain analyze sql ，都会导致集群崩溃？

2. 这个 sql 除了您手工执行，当前业务还在执行吗？是否有并发？

[peng-xin]

1.执行explain会卡死，explain analyze也会卡住，但是没有执行完我就杀掉了
2.没有并发，这个表没有业务在查询

[tiancaiamao (Genius)]

试试 select count(*) 看看表有多大呢？
explain analyze 会卡住正常，不过 explain 不应该呀，可能是前一条已经出问题了，到 explain 这一条语句才在客户端反映出来

[peng-xin]

一共差不多八千万数据，100多个分区

[tiancaiamao (Genius)]

跟这里应该是一个问题
在大的分区表上面，limit 不住，导致读内存读到 OOM 了

https://github.com/pingcap/tidb/pull/16815

[peng-xin]

这是一个bug，需要避免在分区表中进行大跨度的查询吗?

[yilong (yi888long)]

1. 这个之后应该会修复
2. 另一个方面就是尽量要有足够多的内存，看您这边是共部署的吗？ 集群资源如何？
3. 可以先尽量减少大的查询吧。

[peng-xin]

荣老师您好，是混部署的。
但是这个查询很小，就是一个简单的limit 1000。而且机器资源挺充足的。

[yilong (yi888long)]

上面同事答复你了，没有 limit 住导致的。