宕机原因

1.OOM

dmesg -T|grep -i oom #可以这样排查是否oom

原因：

2.X版本OOM原因

• BE 的配置文件 (be.conf) 中 mem_limit 配置不合理

需要配置mem_limit=(机器总内存-其他服务占用内存-1~2g(系统预留))

比如机器内存40G，上面有个Mysql，理论上限会用4G，那么配置下mem_limit=34G (40-4-2)

2.Crash

一般先检查下系统参数配置是否合理，建议参考 https://docs.starrocks.io/zh/docs/deployment/environment_configurations/ 配置。

尤其需要关注ulimit、overcommit和swap参数，检查方式如下

ulimit检查，需要关注max processes和max open files，需要确保>=65535

ulimit -a #查看系统配置
cat /proc/$be_pid_limits #查看be进程配置

image1280×677 209 KB

overcommit检查，以下值应该为 1

cat /proc/sys/vm/overcommit_memory

swap，以下值应该为 0，确保关闭swap

cat /proc/sys/vm/swappiness

如上参数配置正确的前提下，如果还存在crash，可先通过常见 Crash / BUG 堆栈查询判断是不是已知问题

当前crash都会在be.out中打印异常栈，首先获取be.out

• 如果crash中有关键字“LogMessageFatal”，例如发生时间是11月28号，在 be.INFO 中搜下F1128可以看到导致crash的日志

start time: Tue Nov 29 11:45:56 CST 2022
log4j:WARN No appenders could be found for logger (org.apache.hadoop.fs.FileSystem).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
*** Check failure stack trace: ***
    @          0x3feb34d  google::LogMessage::Fail()
    @          0x3fed7bf  google::LogMessage::SendToLog()
    @          0x3feae9e  google::LogMessage::Flush()
    @          0x3feddc9  google::LogMessageFatal::~LogMessageFatal()
    @          0x2d359f5  starrocks::type_dispatch_predicate<>()
    @          0x2d304c3  starrocks::vectorized::VectorizedBinaryPredicateFactory::from_thrift()
    @          0x2ca34e8  starrocks::Expr::create_vectorized_expr()
    @          0x2ca393a  starrocks::Expr::create_tree_from_thrift()
    @          0x2ca39cd  starrocks::Expr::create_tree_from_thrift()
    @          0x2ca39cd  starrocks::Expr::create_tree_from_thrift()
    @          0x2ca3c0f  starrocks::Expr::create_expr_tree()
    @          0x2794b58  starrocks::vectorized::ProjectNode::init()
    @          0x253dd9a  starrocks::ExecNode::create_tree_helper()
    @          0x253df6d  starrocks::ExecNode::create_tree()
    @          0x34eaccd  starrocks::pipeline::FragmentExecutor::_prepare_exec_plan()
    @          0x34ed3e1  starrocks::pipeline::FragmentExecutor::prepare()
    @          0x33a3662  starrocks::PInternalServiceImplBase<>::_exec_plan_fragment()
    @          0x33a5947  starrocks::PInternalServiceImplBase<>::exec_plan_fragment()
    @          0x41296ce  brpc::policy::ProcessRpcRequest()
    @          0x4120137  brpc::ProcessInputMessage()
    @          0x4120fe3  brpc::InputMessenger::OnNewMessages()
    @          0x41c7cae  brpc::Socket::ProcessEvent()
    @          0x40d5c3f  bthread::TaskGroup::task_runner()
    @          0x425e421  bthread_make_fcontext

• 如果没有“LogMessageFatal”关键字，开启pipeline的集群，如果是因为查询导致的be crash，会在be.out中打印query id，拿到query id在fe.audit.log中查找到对应的查询sql，然后获取下query_dump文件（怎么获取query_dump文件），论坛开帖子处理

• 如果非查询导致crash或者未开启pipeline，提供be.out提交帖子处理

• 如果稳定出现crash，建议在一台机器上面开启下core dump，获取下core dump文件分析

core dump获取方式

Core dump只有debug的时候开启，获取完core dump之后必须关闭core dump并重启be