[求助]be crash 内存使用打满 进程突然崩溃

[ijavatar]

be对大查询是有mem limit限制的。这对单条查询确实会有效限制并报错。但对业务上多个大查询同时执行时，限制上可能存在缺陷，导致be进程crash。麻烦确认。
(下述测试并非正常业务逻辑。但因为业务上并行大查询导致be crash，为寻找问题原因模拟再现，采用了以下测试再现。)

【详述】对SR集群做性能测试: join
其中，user_log_perf表量级为2000W、数据模型为明细模型(DUPLICATE KEY)。
发行sql语句如下：
SELECT * FROM perf_test.user_log_perf t1 INNER JOIN perf_test.user_log_perf t2 ON t1.createBy = t2.updateBy;

【步骤】分别从两个客户端向集群发行以上sql。单独发送问题不大，会正确返回mem limit 错误。
但是同时发行几次，就会出现be crash现象，且be错误日志中并无有效信息。且先后出现了3台be中的2台崩溃。
担心mem limit对多个大查询的限制策略存在缺陷。

【业务影响】业务上多个大查询同时发行时be crash、集群不稳定。
【StarRocks版本】fe: 3.0.3、be: 3.1.0-rc01
【集群规模】3fe(8core, 8g)、3be(8core, 16g)
【联系方式】jie zhang(ijavatar@126.com)
【附件】

be.WARNING

[Doni]

集群 fe和be的版本不一致的么

[ijavatar]

是的。之前升级3.1.0-rc01版本。be都成功了、fe出现问题所以回滚了。
文档上写了 be向后兼容fe，而且2周使用下来，其他功能都还稳定，所以就没有回滚。

[许秀不许秀]

be.out 日志发一下看看

[ijavatar]

添附如下。但似乎没啥有用信息。be crash是突然崩溃的。只能从监控参数看到cpu、内存占用率非常高。log中似乎没有太多有用信息。
be.out (5.0 KB)

[许秀不许秀]

确认这样几个事情

1. 是部署在容器中吗
2. BE 是混部的吗
   另外把 dmesg -T的信息也提供一下，看起来是操作系统kill了

[ijavatar]

1. 不是容器，是虚拟机。
2. fe、be单独部署
3. 请教一下，只从以上信息您是从什么地方看出来是操作系统kill了？

[ijavatar]

dmesg文件添附如下
dmesg_t_be3_0724.txt (58.7 KB)

[trueeyu]

把挂之前5分钟的be.info日志发下，小内存机器要特殊配置下。

[许秀不许秀]

看起来是16G的内存，给OS可能预留的太少了，可以提供一下INFO日志，调整一下参数

[Mon Jul 24 14:06:05 2023] Tasks state (memory values in pages):
[Mon Jul 24 14:06:05 2023] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
[Mon Jul 24 14:06:05 2023] [    583]     0   583     9766     1084   118784        0             0 systemd-journal
[Mon Jul 24 14:06:05 2023] [    605]     0   605    66029      110   139264        0             0 lvmetad
[Mon Jul 24 14:06:05 2023] [    618]     0   618    11665      280   126976        0         -1000 systemd-udevd
[Mon Jul 24 14:06:05 2023] [    763]     0   763    13885      100   139264        0         -1000 auditd
[Mon Jul 24 14:06:05 2023] [    786]     0   786     6598       78    98304        0             0 systemd-logind
[Mon Jul 24 14:06:05 2023] [    787]   997   787   204679     2657   245760        0             0 node_exporter
[Mon Jul 24 14:06:05 2023] [    788]    81   788    14556      165   151552        0          -900 dbus-daemon
[Mon Jul 24 14:06:05 2023] [    795]     0   795     5420       70    94208        0             0 irqbalance
[Mon Jul 24 14:06:05 2023] [    797]     0   797   119100      484   368640        0             0 NetworkManager
[Mon Jul 24 14:06:05 2023] [    803]   999   803   153060     1350   274432        0             0 polkitd
[Mon Jul 24 14:06:05 2023] [    804]     0   804    31598      158   114688        0             0 crond
[Mon Jul 24 14:06:05 2023] [    806]    38   806    11826      177   131072        0             0 ntpd
[Mon Jul 24 14:06:05 2023] [   1031]     0  1031   143571     2813   430080        0             0 tuned
[Mon Jul 24 14:06:05 2023] [   1036]     0  1036    28227      256   266240        0         -1000 sshd
[Mon Jul 24 14:06:05 2023] [   1038]     0  1038    55687      621   204800        0             0 rsyslogd
[Mon Jul 24 14:06:05 2023] [   1104]     0  1104    27553       33    65536        0             0 agetty
[Mon Jul 24 14:06:05 2023] [   1144]     0  1144    22429      260   196608        0             0 master
[Mon Jul 24 14:06:05 2023] [   1146]    89  1146    22472      251   204800        0             0 qmgr
[Mon Jul 24 14:06:05 2023] [   2083]  1000  2083 12461767  3998165 74600448        0             0 starrocks_be
[Mon Jul 24 14:06:05 2023] [   4560]    89  4560    22455      251   212992        0             0 pickup
[Mon Jul 24 14:06:05 2023] [   5476]     0  5476    39326      339   360448        0             0 sshd
[Mon Jul 24 14:06:05 2023] [   5479]  1000  5479    39326      338   335872        0             0 sshd
[Mon Jul 24 14:06:05 2023] [   5480]  1000  5480    28921      123    77824        0             0 bash
[Mon Jul 24 14:06:05 2023] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=starrocks_be,pid=2083,uid=1000
[Mon Jul 24 14:06:05 2023] Out of memory: Killed process 2083 (starrocks_be) total-vm:49847068kB, anon-rss:15992660kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:72852kB oom_score_adj:0
[Mon Jul 24 14:06:06 2023] oom_reaper: reaped process 2083 (starrocks_be), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

[ijavatar]

请确认。
be.info.bf_crash_5min (172.6 KB)

另外，关于be的内存限制，文档上记录如下。请问

1. 小内存是指多少以下？
2. mem_limit对小内存机器的默认是没起作用吗？
3. 小内存机器应该如何特殊配置？大内存机器又应该如何配置？
   多谢～
   
   

[ijavatar]

请问具体该如何配置？

[ijavatar]

另外，我试图按https://forum.mirrorship.cn/t/topic/7858去获得core dump文件，并未成功。
是否这种system kill的场景，不会生成core dump文件？

[许秀不许秀]

cat /proc/sys/vm/overcommit_memory 看看这个值是多少

[ijavatar]

@许秀不许秀

overcommit_memory

1
这些参数是严格按照官方文档配置过的

[jingdan]

内存<=16G，需要手动关闭 column pool，并调小chunk_reserved_bytes_limit

be.conf增加配置

disable_column_pool=true
chunk_reserved_bytes_limit=100000000

一般生产环境，BE建议16C64GB以上的配置

[ijavatar]

@jingdan

chunk_reserved_bytes_limit

感谢。我测试一下。
再确认一下。如果是16c、64g以上的话，上述两个参数可以不用设置对吗？

[jingdan]

是的，只有<=16g的时候需要设置上面两个参数

[ijavatar]

再请教一下。这种oom-kill的情况是否不会生成core dump文件？

[jingdan]

oom一般不会，只有异常crash才会生成coredump，oom会在dmesg中打印