StarRocksBE节点崩溃原因查找及解决思路:stdbad_alloc

database

问题分析

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-cn/main/administration/Memory_management#内存管理

设置内存分配参数

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

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

表优化

内存表:StarRocks支持把表数据全部缓存在内存中,用于加速查询,内存表适合数据行数不多维度表的存储。

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

升级StarRocks

新版StarRocks(2.0),对内存管理进行了优化,也可以一定程度上解决问题:

  • 内存管理优化

    • 重构内存统计/控制框架,精确统计内存使用,彻底解决OOM
    • 优化元数据内存使用
    • 解决大内存释放长时间卡住执行线程的问题
    • 进程优雅退出机制,支持内存泄漏检查#1093

欢迎关注微信公众号:数据架构探索

以上是 StarRocksBE节点崩溃原因查找及解决思路:stdbad_alloc 的全部内容, 来源链接: utcz.com/z/536233.html

回到顶部