tidb-server 节点内存疯涨问题求助

Polar · 2021 年6 月 9 日 09:02

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：

【概述】场景 + 问题概述

偶发性tidb-serve节点内存疯涨，几分钟之内内存涨满，导致机器卡死，服务不可用

【背景】做过哪些操作

没有做操作，正常业务访问

【现象】业务和数据库现象

tidb-serve节点卡死，服务不可用

【问题】当前遇到的问题

tidb-serve节点卡死，服务不可用

【业务影响】

【TiDB 版本】

v.4.0.12

【应用软件及版本】

Nodejs

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

profile2.zip (3.7 MB)
tidb-TiDB_2021-06-09T08_13_40.360Z.zip (1.6 MB)

TiUP Cluster Display 信息
TiUP CLuster Edit config 信息

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

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

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

qizheng · 2021 年6 月 9 日 09:31

先检查下业务上是不是有大查询或批量导数任务在跑，如果影响其他业务，可以设置 max_execution_time 在查询或任务执行超时后 kill 掉
上面的 debug 信息是在内存上涨期间抓到的嘛，看上去有一些 expensive query 在跑，超过了设置的内存阈值，也可以把 memory quota 调小一些

image1782×634 89.1 KB

Polar · 2021 年6 月 9 日 09:37

1.debug信息是在内存疯涨的时候抓的。
2.查看了慢sql，没有发现大查询语句。
3.我们发现在db节点内存耗尽时，重启db节点，内存依然会疯涨，尝试重启了2次db，还是会疯涨。
4.停掉应用->重启db->启动应用。db节点还是会疯涨。直到又尝试重启了一遍db，内存才没有再涨

qizheng · 2021 年6 月 9 日 09:39

从 heap 内存占用看，有一些查询在做 HashAgg 聚合，占用近一半内存，所有 tidb 实例日志都检查了嘛，有没有 group by 之类的 SQL；tidb 日志也可以过滤下 expensive_query，如果有会记录 sql

Polar · 2021 年6 月 9 日 09:47

mem-quota-query: 52428800
内存配置的是这

tidb 日志中没有搜索

qizheng · 2021 年6 月 9 日 09:57

slow query 阈值设置多少，grep -i ‘group by’ tidb_slow_query*.log 查一下看看
从上面 profile 看 oom 直接原因应该是 HashAgg 的算子占用的内存较大，目前版本统计内存 quota 并 spill 到磁盘还不支持 HashAgg 算子 https://github.com/pingcap/tidb/issues/22611 ，所以那个 memory quota 对这类算子不生效
对于其他 SQL 生效也需要将 oom-action 设置为 cancel，如果有这类 SQL运行还可以先设置下 max_execution_time 及时 kill 掉

Polar · 2021 年6 月 9 日 14:48

tidb_slow_query-2021-06-09T15-44-56.213.log (4.3 MB)

2021-06-09T15:31 - 2021-06-09T15:36之间的日志。查看了下并没有看到异常sql。我看在31分时内存还正常，35时，已经涨到一半了。

qizheng · 2021 年6 月 10 日 09:49

之前有出现过这种内存的异常上涨吗，麻烦发一下这几分钟的 {cluster-name} - TiDB 监控快照和 tidb.log 日志，我们再看看

Polar · 2021 年6 月 10 日 12:36

以前也会出现，偶发性出现。
帖子附件有监控日志和debug日志
还需要哪个

qizheng · 2021 年6 月 10 日 15:35

deploy_dir/logs 目录下有没有重启之前的 tidb.log 和 tidb_stderr.log

Polar · 2021 年6 月 10 日 15:59

tidb.log (3.0 MB)
tidb_stderr.log (12.2 KB)

出问题时间点附近的日志

qizheng · 2021 年6 月 11 日 04:06

tiup display 看下这个集群的拓扑是怎样的，pd 是不是和其他节点共用的，在内存上涨期间有很多 get TSO timeout 超时报错

qizheng · 2021 年6 月 11 日 04:45

参数设置 "level":"error"，tidb 日志无法记录 INFO 级别的信息，所以没有记录具体的 expensive query，需要改一下日志级别，从 heap top 看内存消耗主要都在 HashAgg 算子上，说明有一些大的聚合计算一直在跑，还是先找到 SQL 进行针对性的优化吧，比如加 hint 走 STREAM AGG 或下推到 tiflash 计算

Polar · 2021 年6 月 11 日 05:32

pd节点上没有其他应用

Polar · 2021 年6 月 11 日 05:51

日志级别已经调整为info了，后续再监控吧。

HashAgg 主要是哪些sql呢？group by / limit / order by还是什么呢

qizheng · 2021 年6 月 11 日 06:22

主要是一些统计类的查询，比如 count/sum/avg/group by 这种，比较适合下推到 tiflash 计算，减少 tidb 内存消耗

Polar · 2021 年6 月 11 日 06:25

好的了解

Polar · 2021 年6 月 11 日 06:28

如果我把oom-action 设置为 cancel ，那么是不是当使用内存到达配置的memory quota大小时，tidb会kill掉当前查询，并返回报错。如果设置 log，会下放硬盘继续执行该sql。是这意思吧

qizheng · 2021 年6 月 11 日 06:54

oom-action 设置为 cancel，如果 oom-use-tmp-storage 为 true，那超过内存阈值会优先输出到临时磁盘文件并不会 kill 掉，并且 memory quota 阈值的统计内存对一些算子可能不够精确。

Polar · 2021 年6 月 11 日 08:09

好的那我调整下配置