背景
在我们支持客户的过程中，发现一些客户在部署和使用StarRocks过程中，遇到BE服务的问题，一般不太清楚应该怎样排查？关注哪些指标？超过多少是不合理的状态等。本文从部署到使用过程中，分享StarRocks BE服务常见问题以及处理办法，希望能帮助大家更好的理解和使用StarRocks。
常见问题及处理方法
部署
下面是部署的一些check项，也可直接使用附录中的Base_check.sh脚本
- 查看CPU是否支持AVX2指令集（因为目前StarRocks的向量化引擎依赖）
#该命令有输出表示CPU是支持avx2的
cat /proc/cpuinfo |grep avx2
- 端口检查
如果下面指令有输出表示默认的端口已经被占用，则需要重新配置端口在fe.conf或be.conf中
FE
ss -antpl|grep -E '8030|9010|9020|9030'
BE
ss -antpl|grep -E '9060|9050|8040|8060'
- 配置必要的内核参数
关闭swap
echo 0 | sudo tee /proc/sys/vm/swappiness
内核允许分配所有的物理内存
echo 1 | sudo tee /proc/sys/vm/overcommit_memory
BE服务宕机
目前StarRocks2.0+版本已经修复了OOM的问题，建议老版本的用户可以升级到2.0+版本
频繁挂掉
如果BE服务挂掉，拉起后还是挂掉，可以在有问题的be服务be.conf中添加以下配置先禁用compaction，然后再重新拉起BE服务，观察是否还会挂。
max_compaction_concurrency=0
如果做了上述操作，BE服务不会由于OOM宕机的话，可以确认原因就是由于compaction导致，可能在此之前导入过大批量的数据。可以尝试调整max_compaction_concurrency=1先让之前导入的数据合并完成（如图starrocks_fe_tablet_max_compaction_score监控项低于50表示当前compaction是没有压力的）。之后可以根据根据max_compaction_concurrency=1时的内存占用适当调整该参数（调整完注意观察参数）。
查询或导入报错：there is no ScanNode backend
show backends查看BE状态
1）如果BE状态为Alive，可能是BE节点hung住，可以尝试重启BE服务恢复
2）如果BE状态为False，查看dmesg -T判断be服务是不是由于oom挂掉了（类似这样的日志：Out of memory: Kill process xxx (starrocks_be)）
a）如果是oom
- 可以先查看/proc/sys/vm/overcommit_memory是否配置为1，若不是先修改该配置为1
- 如果BE与其他服务混部，需要be.conf中配置mem_limit=(机器总内存-其他服务占用内存-1~2g(系统预留))
- 可以查看下当前并行度(show variables like ‘%parallel_fragment_exec_instance_num’)和单个sql内存限制(show variables like ‘%exec_mem_limit’)，当前单个be内存使用也会受限于并行度*exec_mem_limit，可以根据BE节点内存调整这两个变量
b）如果不是oom，需要具体查看be.out日志，在官方论坛 StarRocks数据库论坛 提帖子或者在https://github.com/StarRocks/starrocks/issues提issue
附录
base_check.sh (8.4 KB)