问题剖析

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%

能够经过设置这个选项限制内存占用。

其他内存优化参数能够查看：

docs.starrocks.com/zh-cn/main/…

设置内存分配参数

建议把 cat /proc/sys/vm/overcommit_memory 设成 1。

echo 1 | sudo tee /proc/sys/vm/overcommit_memory

表优化

内存表：StarRocks支撑把表数据悉数缓存在内存中，用于加速查询，内存表适合数据行数不多维度表的存储。

但是内存表在实际运用中优化并不完善，建议暂时先不运用内存表。

升级StarRocks

新版StarRocks(2.0)，对内存办理进行了优化，也能够一定程度上处理问题：

  • 内存办理优化
    • 重构内存计算/控制结构，准确计算内存运用，彻底处理OOM
    • 优化元数据内存运用
    • 处理大内存开释长时间卡住执行线程的问题
    • 进程高雅退出机制，支撑内存泄漏查看#1093

欢迎关注微信公众号：数据架构探究