StarRocks BE节点崩溃原因查找及解决思路:std::bad_alloc
Posted 曲奇饼
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了StarRocks BE节点崩溃原因查找及解决思路:std::bad_alloc相关的知识,希望对你有一定的参考价值。
文章目录
问题分析
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#%E5%86%85%E5%AD%98%E7%AE%A1%E7%90%86
设置内存分配参数
建议把 cat /proc/sys/vm/overcommit_memory 设成 1。
echo 1 | sudo tee /proc/sys/vm/overcommit_memory
表优化
内存表:StarRocks支持把表数据全部缓存在内存中,用于加速查询,内存表适合数据行数不多维度表的存储。
但是内存表在实际使用中优化并不完善,建议暂时先不使用内存表。
升级StarRocks
新版StarRocks(2.0),对内存管理进行了优化,也可以一定程度上解决问题:
- 内存管理优化
- 重构内存统计/控制框架,精确统计内存使用,彻底解决OOM
- 优化元数据内存使用
- 解决大内存释放长时间卡住执行线程的问题
- 进程优雅退出机制,支持内存泄漏检查#1093
欢迎关注微信公众号:数据架构探索
vue项目--浏览器出现卡顿及崩溃的原因查找与解决方案
最近客户反应在操作页面的过程中出现了卡顿甚至交互多一点浏览器直接崩溃了。项目的技术是vue + svg 所以我一直在想是不是svg交互导致的,但是svg涉及的交互也不是很多,不至于产生崩溃状态呀!后来又怀疑是代码问题,于是对大家都知道的一些内存泄露的情况进行了排查:
- 没有全局变量
- 没有定时器
- 没有使用未销毁的全局事件和第三方库
- v-if和v-show合理使用了,v-if和v-for合理使用了
- 没有使用watch
- ...
确保代码层面是没有问题的,但是打开任务管理器,内存的确在随着点击选择交互而飙升。为了排查哪里出了问题,这里使用了vue-devtools
选择Performance
然后点击 Start
进行卡顿的操作后再点击 Stop
,原因一目了然:
Σ(っ °Д °;)っ 找到交互中的下拉框,原来是页面中的下拉框的数据太多了导致的页面卡顿~
解决方案
试将下拉框的数据减少,再进行同样的操作,耗时小了90倍(笑哭~~)
我的业务场景是下拉数据是通过接口一把获取的,之前没有那么多的数据,问题没有暴露,随着业务迭代数据达到几百至几千条。问题暴露了~
一般情况下,在网上可以搜到一堆对下拉数据进行远程搜索和分页处理,而本案例根据实际业务情况进行了下巧妙处理:
第一步:在data中设置一个变量moreNum:20
,表示每次最多显示20条;
第二步:在组件中进行如下操作,当数量多于20条的时候,不再显示
<el-option-group v-for="group in oOtherArr" :key="group.label" :label="group.label">
<template v-for="(item,num) in group.options">
<el-option
:key="item.text"
:label="item.text"
:value="item.text"
v-if="item.text && (group.label === '从库中选择' ? num < moreNum : true)"
></el-option>
</template>
<div
v-if="group.label === '从库中选择' && group.options.length > moreNum"
class="search-keyword-more"
>
只显示前{{moreNum}}条库中结果,请完善搜索关键字
</div>
</el-option-group>
显示结果:
第三步:支持筛选,筛选后返回适配的20条数据
第四步:用户不明觉厉的反馈,哈哈哈~
第五步:总结,小细节引发的大问题,需要记录下,以后再遇到类似操作要学会问题规避和风险预测!
以上是关于StarRocks BE节点崩溃原因查找及解决思路:std::bad_alloc的主要内容,如果未能解决你的问题,请参考以下文章
warning: LF will be replaced by CRLF in ** 的原因及解决办法
python中super出现的TypeError: must be type, not classobj 原因及解决
eclipse中tomcat发布失败(Could not delete May be locked by another process)原因及解决办法
[转]PLS-S-00201, identifier 'CALLDEMO.GET_EMPLOYEES' must be declared 预编译错误原因及解决办法