SQL执行异常

💬 StarRocks 用户问答
#1

【详述】

  1. SQL报错, 报错提示可以调整回话内存设置; 但是没有调整的情况下重新执行SQL, 又没报错
  2. 执行的SQL并不复杂, 而且数据量在千万级别, 并不多; 已经设置了exec_mem_limit , query_mem_limit到20G了, 还是偶发性报错
  3. 这个报错(报错信息见附件)的原理是什么? 怎么解决?

【业务影响】 影响很大, 偶发性失败, 运行不稳定
【StarRocks版本】2.3.11
【集群规模】（fe与be混部, 共6台机器）
【机器信息】80CU, 320G /台
【联系方式】13692280056@163.com
【附件】
1.执行的伪SQL
业务SQL-伪.txt (1.8 KB)

2.报错信息
Exception in thread “main” java.sql.SQLSyntaxErrorException: Memory of Fragment de0d778f-f5df-11ed-8516-b4055ddf14dc exceed limit. try consume:2899353600 Used: 20261817440, Limit: 20737418240. Mem usage has exceed the limit of single query, You can change the limit by set session variable exec_mem_limit or query_mem_limit

3.explain信息
explain_sql.txt (77.1 KB)

4.explain costs信息
explain_costs_sql.txt (131.0 KB)

5.建表信息
建表信息.txt (3.2 KB)

#2

麻烦获取下这个查询的profile

#3

你好, 这个profile是在starrocks的的管理平台查询是吗? 我们这边没有这平台, 有没其它办法拿到呢

#4

我们运维反馈没有开启记录profile参数, 拿不到
能先帮忙指导下这个报错的原理是什么吗? profile目前看来可能要先打开参数, 下次再出现才有profile?

#5

偶发性的内存超限，可能是每次分发到不同BE的计划不同，BE上的内存使用量有区别

或者你可以测试下 不JOIN MYSQL外表看看会不会偶发超内存？

#6

感谢回复
我的表数据量是这样的, t1表约7千万, t2 mysql外表300条, t2的表数量较少, 影响可能没那么大;
我理解的是, 我去掉Join外表的情况下即使没有偶现, 好像也说明不了什么问题, 我还有必要去验证这个场景吗?
对于您的回复, 是不是这样理解:
由于不同BE的当前内存使用情况是有区别的, 所以分发到不同BE的执行计划就会有所区别?

如果这样理解, 我认为确实可以说明了为什么我重试却能成功的问题;

但是还有其它问题没能解释, 根据日志的提示, 我应该设置exec_mem_limit or query_mem_limit 这两项参数;这2个参数默认是8G吧, 但是您可以看到具体提示是超了20G, 说明我其实已经有设置20G了, 但还是会偶现, 虽然频率不高.

从我的查询数据量来看, 根本用不上这么大的会话内存, **所以这2个参数调整的原理是什么, 调整后是作用在计算的哪个环节呢?**希望可以帮忙解释下协助我理解这个错误发生的原理,

另外, 对于这个异常, 我的解决思路是怎样的? 只是调整exec_mem_limit or query_mem_limit参数吗, 如果是, 我应该依据什么来决定调整到多大内存呢?(按数据量来说, 远远匹配不上)

以上, 还请帮忙解决下, 这个是生产环境遇到的问题, 目前还比较头疼, 感谢

#7

您好啊, 今天有时间可以帮忙回复下疑问吗

#8

您好啊, 我的帖子问题两天还没人回复, 可以给看看吗, 焦急呢

#9

https://docs.starrocks.io/zh-cn/latest/administration/query_profile#获取-query-profile 参考下这个帖子来获取下，因为是偶发性问题，所以要先获取下信息才能进一步分析，不能下定论确定是哪里导致的

#10
  1. 如果Mysql的数据量比较少的话，应该影响不大。
  2. 这两个参数主要是限制在查询过程中限制内存使用量，但是限制的未必是真实使用的内存，而是申请量（实际执行过程中要提前预分配内存，但是因为执行过程里数据的不确定，所以申请并不一定会使用，实际上系统也不会统计算这类内存使用），所以会导致出现的情况就是，实际并没有使用到多少内存，但是参数限制住了。
#11

看你这个Plan，所以是7000w的表union 11次，查20个字段？然后实际结果量不大？

猜测内存使用多的地方是这11次scan，由于扫数据是并发执行，可能会在内存堆不少数据。

或者你可以试试执行set pipeline_dop = 20; 或者set pipeline_dop = 10; 看看能不能解决

#12

谢谢回复， 我将内存参数设置到30G后， 后面暂时没再出现过了。后续我会持续观察下。

我这边还有个问题想麻烦大佬帮忙分析下，我这边fe节点的内存占用很高，大概3天左右就会达到80%，然后应该是达到80%后做了内存回收，内存占用会回落到30%左右（用show data看副本量大概50万）。

这个状态还是我们优化了表分区分桶后的，在我们优化前， fe的副本量有1千万，当时的fe内存基本一天有几十次达到80%

现在不知道优化后， Fe节点的这个状态不知道是否健康？是否应该把阈值调整下?80%的状态感觉是不是会有点危险，担心有其它隐患。

附图： fe节点内存监控图

image-20230530170707817
image-20230530170707817929×220 95.3 KB

#13

sql上是不是可以优化下，例如使用with表减少scan，或者通过join的方式来实现数据的11倍膨胀等

#14

这个主要要看有没有长时间的GC，你可以把gc的日志传到https://gceasy.io/这个工具上分析一下。

京ICP备2022026421号-1