【 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]
【遇到的问题:问题现象及影响】
【资源配置】
【附件:截图/日志/监控】
【 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
mem-quota-query
限制且不能再利用临时磁盘时的行为。我这还有临时磁盘可以使用呢,理论上不应该触发action呀
TiDB的某些算子(我印象中有HashJoin)是没办法用到磁盘的,所以在超过mem-quota-query
限制时,很容易导致SQL被KILL掉。你这是生产环境还是测试环境?最新版6.5支持全局内存控制,就可以放心调大单个SQL的mem-quota-query
,只限制总内存使用了
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语句