java.sql.SQLException: Out Of Memory Quota![conn_id=1773197]

【 TiDB 使用环境】生产环境 Poc
【 TiDB 版本】5.1
【复现路径】mem-quota-query=1g
tmp-storage-quota= -1
oom-use-tmp-storage =true
临时文件磁盘有100g空间,为啥还会报错Caused by: java.sql.SQLException: Out Of Memory Quota![conn_id=1773197]

【遇到的问题:问题现象及影响】
【资源配置】
【附件:截图/日志/监控】

修改下 out memory quota 的 action

oom-action

  • 当 TiDB 中单条 SQL 的内存使用超出 mem-quota-query 限制且不能再利用临时磁盘时的行为。
  • 默认值:“cancel”
  • 目前合法的选项为 [“log”, “cancel”]。设置为 “log” 时,仅输出日志。设置为 “cancel” 时,取消执行该 SQL 操作,并输出日志

我这还有临时磁盘可以使用呢,理论上不应该触发action呀

https://docs.pingcap.com/zh/tidb/dev/troubleshoot-tidb-oom#数据库问题

TiDB的某些算子(我印象中有HashJoin)是没办法用到磁盘的,所以在超过mem-quota-query限制时,很容易导致SQL被KILL掉。你这是生产环境还是测试环境?最新版6.5支持全局内存控制,就可以放心调大单个SQL的mem-quota-query,只限制总内存使用了

1 个赞

详细说明见:
https://docs.pingcap.com/zh/tidb/dev/system-variables#tidb_server_memory_limit-从-v640-版本开始引入

tidb 6.4参数tidb_server_memory_limit 是不是等同于设置如下的呢?
resource_control:
memory_limit: “2G”

你的oom-action 配置的是cancel 嘛

是cancel

hash_join中的hash_table可以用到磁盘,但是如果在probe阶段一行匹配出很多行那么这么多记录是无法落盘的,容易导致OOM。
这里应该会修复,但是还在open状态:https://github.com/pingcap/tidb/pull/41081
一般统计信息准确的情况下hash_join发生这种的概率比较小一些吧,因为执行计划总是build小表,probe大表,一般不会出问题。

它这种场景如果不是hashjoin,大概率就是hashagg的问题了,不过也没给个SQL,不知道啥问题。

假设oom-action 设置为cancel,那么一条语句超过mem-quota-query后可能会触发落盘或者是触发流控,那么这条语句在触发落盘或者流控时,是不是会有一个超时时间,比如说在这个超时时间内,落盘和流控还是没能把语句使用的内存降下去,就去触发oom-action的逻辑去cancel语句