2.5.13版本查询导致集群be节点全部OOM

[HYR_888]

为了更快的定位您的问题，请提供以下信息，谢谢
【详述】今天查询导致集群be节点全部OMM了，不知道怎么回事，麻烦技术老师们定位一下
【背景】做过哪些操作？查询
【业务影响】集群be全挂，影响BI查询
【StarRocks版本】2.5.13
【集群规模】3fe（1 master+2follower）+4be（fe与be混部）
【机器信息】CPU虚拟核/内存/网卡，例如：128C/256G/万兆
【联系方式】社区群13-麦咪，谢谢
【附件】

be (2).out (3.4 KB) be (3).out (35.8 KB) be (4).out (609 字节) be.out (4.5 KB)

[jingdan]

可以参考这个看下，[问题排查]BE Crash
dmesg -T看下

[HYR_888]

按照这个流程走不是查询引起的。。我先搞个节点core dump试试
dmesg.log (233.0 KB)

[jingdan]

swap先关闭吧，另外参考 https://docs.starrocks.io/zh-cn/latest/deployment/environment_configurations 把基础配置调整下

[HYR_888]

swap已经关了，我就是按照这个配的

[许秀不许秀]

是混合部署的吧，混合部署需要给其他应用预留一些内存

[HYR_888]

都有预留一些内存

[jingdan]

be的mem_limit配置的多少？fe的jvm配置的多少？

[jingdan]

另外有使用grafana么，看下是哪个模块内存占用高 Grafana模版（支持内存细粒度监控）

[HYR_888]

fe 20G,be 210G

[HYR_888]

这个Grafana没有使用

[HYR_888]

已经找出来导致oom的查询了，麻烦看一下怎么回事
slow_query.txt (16.3 KB)
就是内存超过的话，能不能不要杀死be节点而是杀死查询？

[jingdan]

执行这个sql会稳定复现be oom的问题？建议配置下grafana，方便定位问题

[jingdan]

1.free -g
2.cat /proc/sys/vm/overcommit_memory

这两个结果发下

[HYR_888]

对，从日志上看每次查到这个sql就oom了

[HYR_888]

[jingdan]

执行前和执行过程中多获取几次这个结果，http://be_ip:8040/mem_tracker

[HYR_888]

怎么会这样

[许秀不许秀]

BE 的http页面 不是 FE