表中存在大字段会报Mem usage has exceed the limit of BE

【详述】表查询中存在大字段会报错内存不够用,请问该如何处理
【背景】有一张表在执行insert overwrite select的时候经常出现Mem usage has exceed the limit of BE或者be节点oom,奇怪的是有时候它会执行成功。发现这张表其实数据量6百万条并不大,但是存在一个大字段varchar(70000)。当把这个字段从查询中删除后,语句执行非常稳定,不再出现问题。请帮我解释下问题原因,并请教下如何处理这种情况,可以接受执行慢一点,但想要执行稳定不报错。
【业务影响】
【StarRocks版本】2.5.3
【集群规模】例如:3fe+3be(fe与独立部)
【机器信息】fe:8C/32G be:16C/32G
【联系方式】社区群14-相,谢谢
【附件】


  • 并行度:show variables like ‘%parallel_fragment_exec_instance_num%’;
  • pipeline是否开启:show variables like ‘%pipeline%’;
    image

select 中有什么计算吗

有join或者row_number() over,这两种场景我都是来,都会报错,特别是row_number() over场景下从来没成功过,join场景下还有时候成功过

如果能接受慢的话可以试用一下3.0的spill能力

这个字段,实际平均长度是多长

平均600,最长65536

把SQL和执行计划 发下吧(explain costs)

sql
sql.txt (681 字节)
explain costs
explain.txt (108.8 KB)

加个微信看看?沟通一下试试spill的能力?

从其它帖子中发现有人关掉page_cache后会稳定,试过之后果然不报错了,就是会慢点。慢点总比不稳定强

请教下 spill 是只有部分算子会落盘吗? 比如union会吗

union all 还是 union ?

写的union,但结果集应该没有重合,优化器应该改成union all了可能

union all 本身就是流式处理了,不需要支持spill, union 会被改成AGG,AGG是支持spill的

我们目前有个项目在测试starrocks,大表之间的关联复杂查询,开启了强制落盘,有一定改善,但有些还是会报 内存 mem of process exceed limit,不知是否和并行度太高有关?

并行度太高的确是可能导致使用的内存也比较高,可以降低pipeline_dop试试,然后提供一个profile

目前pipeline_dop调整的是0,这样并行度应该是由引擎自适应调整?我们指定一个值看下表现。 另外, 并行度是否还和fragment_pool_thread_num_min 、fragment_pool_thread_num_max 这两个有关系吗?这两个是限制系统整体的还是 一次查询的呢?

pipeline跟这个没有关系了