高并发查询BE Crash

为了更快的定位您的问题,请提供以下信息,谢谢
【详述】问题详细描述
试用新版本集群3.3.3 ,部署成功后,进行压测,高并发100就会直接crash 重启,稳定复现
【业务影响】
BE 直接崩溃重启,影响所有查询
【是否存算分离】 否
【StarRocks版本】3.3.3/3.3.4
【集群规模】例如:6fe(3 follower+3observer)+ 20 be
【机器信息 48C/196G/万兆
【联系方式】
【附件】
be.log.tar.gz (46.2 MB)

  • be crash
*** Aborted at 1728996167 (unix time) try "date -d @1728996167" if you are using GNU date ***
PC: @          0x3668ee7 std::_Sp_counted_ptr_inplace<starrocks::RuntimeProfile, std::allocator<starrocks::RuntimeProfile>, (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)
*** SIGSEGV (@0x22) received by PID 14898 (TID 0x7fb79cbc1700) from PID 34; stack trace: ***
    @     0x7fb955c1620b __pthread_once_slow
    @          0x79c3320 google::(anonymous namespace)::FailureSignalHandler(int, siginfo_t*, void*)
    @     0x7fb955c1f630 (/usr/lib64/libpthread-2.17.so+0xf62f)
    @          0x3668ee7 std::_Sp_counted_ptr_inplace<starrocks::RuntimeProfile, std::allocator<starrocks::RuntimeProfile>, (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)
    @          0x6000435 starrocks::SegmentIterator::_finish_late_materialization(starrocks::SegmentIterator::ScanContext*)
    @          0x600d83c starrocks::SegmentIterator::_do_get_next(starrocks::Chunk*, std::vector<unsigned int, std::allocator<unsigned int> >*)
    @          0x600f620 starrocks::SegmentIterator::do_get_next(starrocks::Chunk*)
    @          0x6082323 starrocks::ProjectionIterator::do_get_next(starrocks::Chunk*)
    @          0x69401a5 starrocks::SegmentIteratorWrapper::do_get_next(starrocks::Chunk*)
    @          0x6725a03 starrocks::TimedChunkIterator::do_get_next(starrocks::Chunk*)
    @          0x60b7ed4 starrocks::TabletReader::do_get_next(starrocks::Chunk*)
    @          0x45a2100 starrocks::pipeline::OlapChunkSource::_read_chunk_from_storage(starrocks::RuntimeState*, starrocks::Chunk*)
    @          0x45a2871 starrocks::pipeline::OlapChunkSource::_read_chunk(starrocks::RuntimeState*, std::shared_ptr<starrocks::Chunk>*)
    @          0x4598b7a starrocks::pipeline::ChunkSource::buffer_next_batch_chunks_blocking(starrocks::RuntimeState*, unsigned long, starrocks::workgroup::WorkGroup const*)
    @          0x425a483 auto starrocks::pipeline::ScanOperator::_trigger_next_scan(starrocks::RuntimeState*, int)::{lambda(auto:1&)#1}::operator()<starrocks::workgroup::YieldContext>(starrocks::workgroup::YieldContext&) const [clone .constprop.0]
    @          0x436a84e starrocks::workgroup::ScanExecutor::worker_thread()
    @          0x382b71b starrocks::ThreadPool::dispatch_thread()
    @          0x3824c46 starrocks::Thread::supervise_thread(void*)
    @     0x7fb955c17ea5 start_thread
    @     0x7fb95501896d __clone

每次Crash都是这个堆栈吗?

是的,所有节点都一样。如有需要提供更多信息,可以添加飞书:screenshot-20241022-065402