共计 2426 个字符，预计需要花费 7 分钟才能阅读完成。
问题剖析
StarRocks BE 5 个节点忽然在几分钟内全副掉线。查找 BE 的 be.out 日志，输入如下：
tcmalloc: large alloc 1811947520 bytes == 0x77f9f0000 @ 0x384f94f 0x39ce2dc 0x399646a
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
*** Aborted at 1641348199 (unix time) try "date -d @1641348199" if you are using GNU date ***
PC: @ 0x7fa8c7db4387 __GI_raise
*** SIGABRT (@0x2ab9) received by PID 10937 (TID 0x7fa7f0658700) from PID 10937; stack trace: ***
@ 0x2da5562 google::(anonymous namespace)::FailureSignalHandler()
@ 0x7fa8c99cc630 (unknown)
@ 0x7fa8c7db4387 __GI_raise
@ 0x7fa8c7db5a78 __GI_abort
@ 0x12e91ff _ZN9__gnu_cxx27__verbose_terminate_handlerEv.cold
@ 0x391d6f6 __cxxabiv1::__terminate()
@ 0x391d761 std::terminate()
@ 0x391d8b5 __cxa_throw
@ 0x12e80de _ZN12_GLOBAL__N_110handle_oomEPFPvS0_ES0_bb.cold
@ 0x39ce27e tcmalloc::allocate_full_cpp_throw_oom()
@ 0x399646a std::__cxx11::basic_string<>::_M_mutate()
@ 0x3996e90 std::__cxx11::basic_string<>::_M_replace_aux()
@ 0x1c5c4fd apache::thrift::protocol::TBinaryProtocolT<>::readStringBody<>()
@ 0x1c5c6ac apache::thrift::protocol::TVirtualProtocol<>::readMessageBegin_virt()
@ 0x1e3d3c9 apache::thrift::TDispatchProcessor::process()
@ 0x2d91062 apache::thrift::server::TConnectedClient::run()
@ 0x2d88d13 apache::thrift::server::TThreadedServer::TConnectedClientRunner::run()
@ 0x2d8ab10 apache::thrift::concurrency::Thread::threadMain()
@ 0x2d7c500 _ZNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFvSt10shared_ptrIN6apache6thrift11concurrency6ThreadEEES8_EEEEE6_M_runEv
@ 0x3998d40 execute_native_thread_routine
@ 0x7fa8c99c4ea5 start_thread
@ 0x7fa8c7e7c9fd __clone剖析日志，关键词是：std::bad_alloc
显然是内存不够产生了雪崩效应，如果节点比拟多，可能不会都挂掉。BE 是 C ++ 开发的，谬误解释参考：https://www.zhihu.com/question/24926411
operator new 抛 bad_alloc 算是比较严重的资源问题了，因为无奈分配内存，对象无奈结构，必定不能依照原来的逻辑运行了，而且很可能连给你 clean up 的内存都不够。
在这种状况下，让程序挂掉是正确的做法 …
解决思路
减少内存
最好的办法必定是减少内存。毕竟随着数据量减少，对内存应用必然会减少，可能就无奈应答忽然导入数据量增大的状况。
优化导入配置
在 StarRocke 以后版本 (1.19) 中有一个配置项：
mem_limit=80% # BE 能够应用的机器总内存的比例，如果是 BE 独自部署的话，不须要配置，如果是和其它占用内存比拟多的服务混合部署的话，要独自配置下
load_process_max_memory_limit_bytes=107374182400 # 单节点上所有的导入线程占据的内存下限，100GB
load_process_max_memory_limit_percent=80 # 单节点上所有的导入线程占据的内存下限比例，80%能够通过设置这个选项限度内存占用。
其余内存优化参数能够查看：
https://docs.starrocks.com/zh…
设置内存调配参数
倡议把 cat /proc/sys/vm/overcommit_memory 设成 1。
echo 1 | sudo tee /proc/sys/vm/overcommit_memory表优化
内存表：StarRocks 反对把表数据全副缓存在内存中，用于减速查问，内存表适宜数据行数不多维度表的存储。
然而内存表在理论应用中优化并不欠缺，倡议临时先不应用内存表。
降级 StarRocks
新版 StarRocks(2.0)，对内存治理进行了优化，也能够肯定水平上解决问题：
-
内存治理优化
- 重构内存统计 / 管制框架，准确统计内存应用，彻底解决 OOM
- 优化元数据内存应用
- 解决大内存开释长时间卡住执行线程的问题
- 过程优雅退出机制，反对内存透露查看 #1093
欢送关注微信公众号：数据架构摸索
正文完