近期BE频繁挂掉,请帮忙分析下

近期以来,数据日增3000W+,开始(10月8日)出现BE进程掉线的情况,起初是只掉一台,重开BE以后正常运行3到4天,然后掉2台,重开以后运行2到3天,然后3台全掉,重开以后运行一段时间再次全掉,短则5分钟,长则半天左右。10月17日升级2.2.8以后现象依旧
【StarRocks版本】原2.2.2,后升级2.2.8
【集群规模】例如:3fe(3follower)+3be(全独立部署)
【机器信息】CPU52核104线程,256G内存,10G网卡,系统CENTOS 7
【附件】
3台BE地址分别为:154.111.1.38、154.111.1.41、154.111.1.42,以下上传其中一台be(41)日志,最近一次掉线时间为10-18 09:27前后,未发现OOM错误

query_id:00000000-0000-0000-0000-000000000000
*** Aborted at 1666056468 (unix time) try “date -d @1666056468” if you are using GNU date ***
PC: @ 0x416239c run_container_andnot
*** SIGSEGV (@0x0) received by PID 38015 (TID 0x7f6c3cb49700) from PID 0; stack trace: ***
@ 0x3cf85d2 google::(anonymous namespace)::FailureSignalHandler()
@ 0x7f6c99db5630 (unknown)
@ 0x416239c run_container_andnot
@ 0x4160ab9 run_run_container_andnot
@ 0x4160aef run_run_container_iandnot
@ 0x4146ad5 roaring_bitmap_andnot_inplace
@ 0x1a6b0de starrocks::vectorized::SegmentIterator::_apply_bitmap_index()
@ 0x1a6fe4a starrocks::vectorized::SegmentIterator::_init()
@ 0x1a70539 starrocks::vectorized::SegmentIterator::do_get_next()
@ 0x1acd5b2 starrocks::vectorized::ProjectionIterator::do_get_next()
@ 0x1e2dc0a starrocks::SegmentIteratorWrapper::do_get_next()
@ 0x1b0566b starrocks::vectorized::TimedChunkIterator::do_get_next()
@ 0x1afe0ce starrocks::vectorized::TabletReader::do_get_next()
@ 0x27c9c4d starrocks::pipeline::OlapChunkSource::_read_chunk_from_storage()
@ 0x27ca2d0 starrocks::pipeline::OlapChunkSource::buffer_next_batch_chunks_blocking()
@ 0x27cd573 _ZNSt17_Function_handlerIFvvEZN9starrocks8pipeline12ScanOperator18_trigger_next_scanEPNS1_12RuntimeStateEiEUlvE0_E9_M_invokeERKSt9_Any_data
@ 0x1e54dd0 starrocks::PriorityThreadPool::work_thread()
@ 0x3c93c07 thread_proxy
@ 0x7f6c99dadea5 start_thread
@ 0x7f6c993c8b0d __clone
@ 0x0 (unknown)

be.out (16.9 KB) be.WARNING.log.20220830-104026 (11.2 MB)

1.BE宕机前CPU,内存,IO使用率高吗?
2.grep ERR fe.audit.log 搜索一下是不是某个SQL引起BE宕机的?

BE进程挂掉前占用正常,FE日志能帮看一下吗,我看不懂 :joy:
这个是截取的掉线前后的一段日志
fe.audit.log.txt (19.4 KB)

您发的都是BE宕机后的吧,宕机前的看看吧

应该是BUG,可以开下core dump,获取个Core文件,发给我们,我们来分析下吗。

有这个时间点的内存监控吗

启动BE前, 执行下ulimit -c unlimited 开个Core,万一再Crash,可以获取到更多 信息

加个微信,一起分析下这个问题?

谢谢大神回复,ulimit -c unlimited 已经开了,我再观察一下,等BE再挂

加个微信,沟通下这个问题?

好的,我私信你,刚刚其中一个BE又挂了,因为在导数据,所以半个小时产生了23G的一个CORE文件,太大了

内存应该没有问题

压缩下,应该有1G

基本确认是RoaringBitmap的一个BUG,已修复。