BE每30分钟挂 一次，可以帮帮忙吗

💬 StarRocks 用户问答
#1

机器为单节点8v 32g
StarRocks的版本号是：3.2.6
基本每30分钟挂掉一次，内存使用大概在20%-30%之间，be.out没有任何信息，只有一行start time: 2024年 08月 30日 星期五 00:08:06 CST，也尝试生成coredump，但是没有生成任何文件，我尝试手动kill -s SIGSEGV 29957，是有coredump文件，be.out也有记录。
目前看到的只有info的日志，
be.INFO.log.20240830-000807 (25.8 MB) be.INFO.log.20240829-163130 (67.9 MB)
I0829 23:59:51.562207 3951 daemon.cpp:197] Current memory statistics: process(12061457096), query_pool(8702193728), load(0), metadata(14835894), compaction(0), schema_change(0), column_pool(0), page_cache(2787533680), update(12011), chunk_allocator(359149752), clone(0), consistency(0), datacache(0)
I0829 23:59:51.593860 4314 load_channel_mgr.cpp:249] Memory consumption(bytes) limit=5437707779 current=0 peak=17965224

be.conf配置文件：
disable_column_pool=true
mem_limit = 60%
buffer_stream_reserve_size=8192

/etc/sysctl.conf
vm.overcommit_memory = 1
vm.swappiness = 0
sysctl -p

dmesg信息
[root@gddb crash]# dmesg -T|grep -i oom
[四 8月 29 20:00:00 2024] Jprotobuf-RPC-C invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[四 8月 29 20:00:00 2024] [] oom_kill_process+0x2d5/0x4a0
[四 8月 29 20:00:00 2024] [] ? oom_unkillable_task+0xcd/0x120
[四 8月 29 20:00:00 2024] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
[四 8月 29 20:00:01 2024] in:imjournal invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[四 8月 29 20:00:01 2024] [] oom_kill_process+0x2d5/0x4a0
[四 8月 29 20:00:01 2024] [] ? oom_unkillable_task+0xcd/0x120
[四 8月 29 20:00:01 2024] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
[四 8月 29 20:59:58 2024] VM Periodic Tas invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[四 8月 29 20:59:58 2024] [] oom_kill_process+0x2d5/0x4a0
[四 8月 29 20:59:58 2024] [] ? oom_unkillable_task+0xcd/0x120
[四 8月 29 20:59:59 2024] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
[四 8月 29 20:59:59 2024] mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[四 8月 29 20:59:59 2024] [] oom_kill_process+0x2d5/0x4a0
[四 8月 29 20:59:59 2024] [] ? oom_unkillable_task+0xcd/0x120
[四 8月 29 20:59:59 2024] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
[四 8月 29 20:59:59 2024] edr_agent invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[四 8月 29 20:59:59 2024] [] oom_kill_process+0x2d5/0x4a0
[四 8月 29 20:59:59 2024] [] ? oom_unkillable_task+0xcd/0x120
[四 8月 29 20:59:59 2024] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
[四 8月 29 21:59:58 2024] query_ctx_clr invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[四 8月 29 21:59:58 2024] [] oom_kill_process+0x2d5/0x4a0
[四 8月 29 21:59:58 2024] [] ? oom_unkillable_task+0xcd/0x120
[四 8月 29 21:59:58 2024] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
[四 8月 29 22:59:58 2024] VM Thread invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[四 8月 29 22:59:58 2024] [] oom_kill_process+0x2d5/0x4a0
[四 8月 29 22:59:58 2024] [] ? oom_unkillable_task+0xcd/0x120
[四 8月 29 22:59:58 2024] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
[五 8月 30 00:00:00 2024] pip_wg_executor invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0
[五 8月 30 00:00:00 2024] [] oom_kill_process+0x2d5/0x4a0
[五 8月 30 00:00:00 2024] [] ? oom_unkillable_task+0xcd/0x120
[五 8月 30 00:00:00 2024] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
[五 8月 30 00:00:00 2024] edr_agent invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[五 8月 30 00:00:00 2024] [] oom_kill_process+0x2d5/0x4a0
[五 8月 30 00:00:00 2024] [] ? oom_unkillable_task+0xcd/0x120
[五 8月 30 00:00:00 2024] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
[五 8月 30 07:59:57 2024] pip_wg_executor invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[五 8月 30 07:59:57 2024] [] oom_kill_process+0x2d5/0x4a0
[五 8月 30 07:59:57 2024] [] ? oom_unkillable_task+0xcd/0x120
[五 8月 30 07:59:57 2024] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
[五 8月 30 07:59:58 2024] sfavsrv invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[五 8月 30 07:59:58 2024] [] oom_kill_process+0x2d5/0x4a0
[五 8月 30 07:59:58 2024] [] ? oom_unkillable_task+0xcd/0x120
[五 8月 30 07:59:58 2024] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
[五 8月 30 08:59:57 2024] pip_wg_executor invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0
[五 8月 30 08:59:57 2024] [] oom_kill_process+0x2d5/0x4a0
[五 8月 30 08:59:57 2024] [] ? oom_unkillable_task+0xcd/0x120
[五 8月 30 08:59:57 2024] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
[五 8月 30 08:59:57 2024] sfavsrv invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[五 8月 30 08:59:57 2024] [] oom_kill_process+0x2d5/0x4a0
[五 8月 30 08:59:57 2024] [] ? oom_unkillable_task+0xcd/0x120
[五 8月 30 08:59:57 2024] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name

这个8:59和挂掉的时间比较稳合，但是coredump却没有日志。
实在感谢！

#2

有大佬可以帮忙分析一下吗，感激不尽，实在无法理解查询速度这么快的库，为什么会有这么不稳定的情况 :joy:

#3

发个完整的dmesg

1赞
#4

目前问题已确定，正在找处理办法，导出了dmesg，确认是out of memory引起OOM，我将starrocks_be的oom_score_adj设置为了-1000，禁止OOM进行查杀后，系统不一会就挂掉，挂掉前系统内存100%，starrocks_be使用内存90%以上，
目前正在想办法，请问有好的建议吗
我正在通过设置mem_limit进行限制，不清楚是否还有其它参数可以限制。

#5

混合部署的吗？混合部署得给其他进程留点内存

#6

存算一体的，另外这台机上面有很多服务程序。就是不知道mem_limit这个参数是否限制得到最大的内存使用量。

#7

问题已解决，调整mem_limit后，至今运行正常。此问题的关键点在于没有相关的监控，内存会短时间上升到100%导至被OOM，OOM后系统也无任何日志可以查询，最后通过dmesg导出日志后才进行了确认，感谢解答。

京ICP备2022026421号-1