starRocks的BE节点宕机

在starRocks2.5.13,3fe+4be经常会发生8040和8060会宕机,这个有什么办法能解决的 。下面是监控视图

会严重影响到查询效率和数据同步113be.out (2.3 MB) 113zzf.txt (288.9 KB) 214be.out (2.3 MB) 214zzf.txt (2.4 MB) be.out (2.2 MB) zzf.txt (288.6 KB)

10月24号后有做过集群升级之类的操作么,看日志中上次重启是 11月16号 10:36:36,当时是异常重启么 还是手动重启的

https://docs.starrocks.io/zh/docs/2.5/deployment/environment_configurations/ 参考这个文档看下当前集群的几个系统配置项是否按照建议值修改,不是建议的值参数修改后,发一下修改了哪些参数

监控上的 dead 的时候,相关be.warning 日志中有什么异常信息么

那时候数仓这边有进行升级,从2.5.10升级为2.5.13版本,是手动重启的

我be.conf上面的参数配置是这样子设计的:image
fe.conf上面的参数配置是这样子设计的:


fe的配置是8核+32G,be的配置是16核+64G

be.warning上面显示的日志也是这样子:

这个是发生dead的时候

监控上显示 dead,实际看进程没有重启过,监控上dead的节点一段时间后是自动恢复正常的么

这个be.warning 是 63节点的么,不是的话,再看一下 63节点在这个时间段附近的be.warning 日志

这个是63那台的be的warming

可以自动恢复,但是高负载的be情况下就会导致很多be的8040和8060端口服务挂掉了

老师,您好。能否加一下您的微信,不然有时候回复得比较不及时,沟通问题不方便

这个怎么知道哪些桶有问题,这个具体要怎么修复呢

看be.out和监控,分析是误报,误报的原因,是IO比较高导致,为什么IO高会导致误报,需要通过日志分析下

原因是导入太频繁,Compaction占用磁盘IO比较多,IoWait比较高导致.
update information_schema.be_configs set value=32 where name=‘min_cumulative_compaction_num_singleton_deltas’;
恢复正常