v4.0.13 oom-action没作用

Lawrence · 2021 年6 月 23 日 12:46

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

【概述】场景+问题概述
测试环境，tidb节点15G内存，设置了oom-action为cancel，performance.server-memory-quota为10个G，
compatible-kill-query一个节点设置的5个G，一个节点设置15个G，想测下单条sql超过5G被kill掉、超过10G是performance.server-memory-quota起作用，但是发现并没有效果，在9节点执行的，跑满了15G内存，既没有被compatible-kill-query kill掉，也没有被performance.server-memory-quota kill掉，tidb节点还是挂机了

就只报了个警报：

重启：

【TiDB 版本】
V4.0.13

和这个一样，不起作用，不只是groupby，都不行。

yilong · 2021 年6 月 24 日 02:27

试试把 oom-use-tmp-storage 设置为 false 能否 kill ，多谢。

Lawrence · 2021 年6 月 24 日 03:55

以改为false，并吧所有的参数全部调低，server内存只能用3G，query内存一个设置的1G，一个设置的5G，仍然不管用

最开始状态：

过程中：

配置参数：

1624506707(1)

日志：
tidb (1).zip (7.0 KB)

yilong · 2021 年6 月 24 日 06:08

麻烦发一下你的sql 和 explain analyze sql 的结果，建表语句。
如果 explain analyze sql 无法执行成功就先不上传了。

Lawrence · 2021 年6 月 24 日 06:13

建表语句和sql：
sub3.sql (144.3 KB)

yilong · 2021 年6 月 24 日 06:21

目前如果是走 hashagg 内存可能trace不上，导致无法正常 cancel.
你再执行一次这个sql，再执行过程中，采集以下profile文件。
curl -G http://{TiDBIP}:10080/debug/zip?seconds=30" > profile.zip
ip地址为tidb服务器的ip，端口为tidb_status_port的端口

Lawrence · 2021 年6 月 24 日 06:28

profile如下：
profile.zip (155.6 KB)

Lawrence · 2021 年6 月 24 日 08:19

@yilong 大佬，这个分析出来了吗

Lawrence · 2021 年6 月 24 日 10:00

另外即使是hashagg的trace不上，那整个tidb机器的内存使用好监控到吧，为啥没被这个规则kill掉呢

yilong · 2021 年6 月 28 日 02:41

从火焰图看，应该是hashagg 导致的，目前 trace 不到，所以设置的参数无法 kill

image1070×460 59.1 KB
系统层面无法监控单个sql，只能设置 OOM 的内存阈值
不知道设置参数 max_execution_time 是否可行？
https://docs.pingcap.com/zh/tidb/stable/system-variables#max_execution_time

Lawrence · 2021 年6 月 28 日 03:06

那就是mem-quota-query这个参数对hashagg捕捉不到，所以无法生效是吧，希望官方文档能明细下
performance. server-memory-quota这个参数说的是如果服务器内存占用到阈值，则随机kill，并不是监控的单个sql吧，所以这个也没生效

image977×540 31.7 KB
max_execution_time这个不太可行，因为可能有的sql执行时间长单并没有占用较大内存，会被误kill

yilong · 2021 年6 月 29 日 11:50

嗯，应该是也没生效。
https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#oom-use-tmp-storage
目前这种问题，是希望使用 oom-use-tmp-storage 参数代替。
https://github.com/pingcap/tidb/issues/8799 PR 中也有描述，您可以尝试，如果还有问题请继续反馈。