tidb-server服务使用内存飙升

[getui]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
v4.0.11
【概述】 场景 + 问题概述
突然出现tidb-server内存飙升
报错：

监控：

【背景】 做过哪些操作

【现象】 业务和数据库现象
查询耗时非常长，几乎不可用
【问题】 当前遇到的问题
希望帮忙分析原因
【业务影响】

【TiDB 版本】

【应用软件及版本】

【附件】 相关日志及配置信息

• TiUP Cluster Display 信息
• TiUP CLuster Edit config 信息

监控（https://metricstool.pingcap.com/)

• TiDB-Overview Grafana监控
• TiDB Grafana 监控
• TiKV Grafana 监控
• PD Grafana 监控
• 对应模块日志（包含问题前后 1 小时日志）

---

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

[h5n1]

先排查下有没有大数量查询，看下慢SQL

[getui]

从流量图上看：
这段时间写的流量略大：

[getui]

嗯，有个慢查询sql一直在执行的，为啥突然就飙升了，写影响了？

[h5n1]

可能返回tidb server的数据量太大，看下执行计划

[getui]

还有，有几个sql执行的频率非常高

[这道题我不会 (Lizhengyang@PingCAP)]

1.重点排查下问题时间点的慢 SQL 情况，查询下哪些 SQL 开销最大，可以使用下面这条 SQL 先核实下扫描 region 最多的几个 SQL ，然后看下 SQL 对应的执行计划是否存在全表扫描等情况：

select query_time, query, digest
from information_schema.cluster_slow_query
where is_internal = false  
  AND time >= '2021-10-15 xx:xx:00'
  AND time < '2021-10-15 xx:xx:00'
order by Process_keys desc
limit 5;

2.上面几个高频 SQL 需要让业务研发侧看下请求是否合理。

[haizi]

按照你给的这个查询条件，在这个异常的时间段内，是有一个全表扫描的语句，查的这个表有6w记录，正常执行的话，这个语句只需要0.3秒，之前一直在执行的。在异常的这个时间段内，执行需要5-7秒。

[haizi]

具体的语句及执行计划

[这道题我不会 (Lizhengyang@PingCAP)]

1.这条 SQL 没有过滤条件直接全表扫描，如果表数据量突然变大或者查询频率突然升高，都会给系统带来很大的影响，建议添加一些过滤条件；
2.其他的 TOPSQL 和高频 SQL 都重点看下吧，tidb-server 是纯计算层，内存突然飙升大概率都是高消耗的 SQL 导致的。

[haizi]

当时还有大量的这个语句在执行，每个执行完都需要6 7分钟。这个是什么原因啊？

[这道题我不会 (Lizhengyang@PingCAP)]

这些 SQL 应该是受害者，源头是哪些业务 TOPSQL 导致整个集群的负载上升，原先正常执行的 SQL 由于不能及时获取到资源，执行消耗时间也会变长，从日志中看这些 SQL 也就变成了慢 SQL

[林先森cC]

看tidb日志最早有这个报错 不知道是什么含义

[这道题我不会 (Lizhengyang@PingCAP)]

这个时间段该 tidb-server 负载应该很高了吧，相关请求打过来时 tidb-server 无法及时处理，发生了 panic

[林先森cC]

看监控是PD的三台节点机器 压力很大，差不多从00:54分开始上涨

看机器的message日志

有报这个错

[qizheng]

查询 information_schema.cluster_slow_query 表还可以按照 Mem_max 内存使用量做一下排序

[haizi]

还有一个疑问，就是从 information_schema.cluster_slow_query查出来的每个慢sql，最大的也就占用6MB的内存，为啥这里突然一下子内存飙升那么高 ？瞬时把内存占完了？