3.0.5版本broker节点频繁挂掉

【详述】broker节点频繁报内存溢出然后挂掉
【背景】做过哪些操作?
【业务影响】brokerload导数失败
【是否存算分离】否
【StarRocks版本】3.0.5
【集群规模】例如:3fe +4be(fe与be混部)+4broker
【机器信息】72C/380G/万兆
【联系方式】阿坚
【附件】
broker一共四个和be个数保持一致,内存也调整过,根据官方文档设置的query_mem_limit是200g,四台broker每台都200g内存根本不可能内存溢出啊,是不是参数设置的不对?


1703469066156

broker报错信息:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/d/p2/app/StarRocks/apache_hdfs_broker/lib/slf4j-reload4j-1.7.36.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/d/p2/app/StarRocks/apache_hdfs_broker/lib/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Reload4jLoggerFactory]
Exception in thread “Thread-0” java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:717)
at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1378)
at org.apache.thrift.server.TThreadPoolServer.execute(TThreadPoolServer.java:155)
at org.apache.thrift.server.TThreadPoolServer.serve(TThreadPoolServer.java:139)
at com.starrocks.common.ThriftServer$1.run(ThriftServer.java:96)
at java.lang.Thread.run(Thread.java:748)

看报错是Broker进程的内存超出Jvm限制了,3.0建议不使用独立的Broker,可以使用StarRocks直连试试。Broker进程的Jvm配置了多少内存?

哪里设置的broker进程的JVM内存啊,我看broker下面的配置文件里也没有设置JVM内存的参数啊?

start_broker.sh里应该是写死的配置,你可以改下试试.
export JAVA_OPTS="-Xmx1024m -Dfile.encoding=UTF-8"
一般不会超限的,你们有比较长的字符串,或是表的列比较多?

有两个导入的作业都有134个列,跟这个有关系?
内存设置1g够用吗?

默认是1G,可以调大,比如4G,试试

我把broker虚拟机内存调到了10g,今天又崩掉了;难道10g也不够?

我现在调整到了20g ,不知道到底是不是这个原因

BrokerLoad 导入本地文件失败,type:LOAD_RUN_FAIL,msg:No more data to read 兄弟看看我这个问题的情况和你有类似的地方么

应该不一样,我的broker节点数量和be节点数量保持一致,按照官网介绍,每个be各自在自己的机器上读取broker的数据。最近频繁崩溃可能和导数的数据量和任务量翻倍有关,同一分数据会相继推A,B两个表。每小时有上百个任务,翻倍就相当于200个任务

我发那个参数是控制be向broker读取数据的并发度的。看你的报错像是broker创建的线程太多了。当导入任务比较大的时候,FE会将任务分开丢给所有BE去处理,而每个BE又会有多个任务并发,这些任务都需要和Broker通信,每个任务都有一个连接,很可能把Broker的线程打爆了

你说到这,我服务器设置好的最大用户进程数,不知道今天被谁给改了,有可能是运维改的。我设置的max user processes 40960被改成了4096,之前就是这个参数太小导致的be节点老是崩溃,现在我怀疑是这个参数被改掉的原因~

看上去很有可能啊

已破案,就是运维改的最大用户进程数导致的,已经联系运维固定最大用户进程数。