BE参数默认值与实际运行值不一致

为了更快的定位您的问题,请提供以下信息,谢谢
【详述】
be以下两个参数:
load_channel_rpc_thread_pool_queue_size
load_segment_thread_pool_queue_size
看官网文档显示默认值都是2048



但我从http://BE ip:8040/varz 中获得,
load_channel_rpc_thread_pool_queue_size = 1024000
load_segment_thread_pool_queue_size = 10240
image
image

这两参数在be.conf中没有显式配置,请问这是文档未更新,还是3.5版本的默认有问题?
另外还有很多 http://BE ip:8040/varz 中看到的参数,在官网是查不到的,所以也无法知道参数含义及配置值是否要调整

【背景】无
【业务影响】
【是否存算分离】否
【StarRocks版本】3.5.12
【集群规模】3fe+3be(fe与be独立部署)
【机器信息】40C/256G/千兆
【联系方式】社区群24-Hanson,谢谢

你这个是直接部署3.5版本么?还是从其他版本升级上来的?

从3.1.15版本升级上来的,升级顺序:3.1.15 → 3.1.17 → 3.2.16 → 3.3.22 → 3.4.10 → 3.5.12

那就是正常的

Fix: https://github.com/StarRocks/starrocks/pull/72742

load_channel_rpc_thread_pool_queue_size = 1024000
load_segment_thread_pool_queue_size = 10240
那这两个值配置合理吗?load_channel_rpc_thread_pool_queue_size = 1024000 是不是太大了?

还有个参数 brpc_connection_type 这个看默认值是 single,但是我目前配置的是 pooled(是当时3.1.15版本集群不稳定时加入这个pooled配置),这个对集群稳定有影响吗?现在be.warning中每天有一两千条connection reset by peer和connection time out报错

建议用pooled,be.WARNG这些报错,用户感知不到吧

有感知的,另外今天发现brpc workers监控有异常,3台be节点上限都是49(cpu是48核),但是已使用有1台be节点异常高,详见截图


这个监控是对应参数brpc_num_threads吗?看默认值是-1,代表与cpu核数相同。这个异常点会是导致大量connection reset by peer和connection time out报错的根源吗?

客户端会报错?

业务端SQL执行有失败的,但跟这个频繁报错不知道有没有关系。
在be.warning中找到如下错误:

W20260511 09:50:14.748533 23194022319872 pipeline_driver.cpp:601] cancel pipeline driver error [driver=query_id=b87fd4bd-4cdb-11f1-b570-a0369fd7e4a8 fragment_id=b87fd4bd-4cdb-11f1-b570-a0369fd7e4ab driver=driver_0_13 addr=0x1517d83cc410, status=RUNNING, operator-chain: [olap_scan_0_0x1517db35a710(X) { full:false iostasks:4 has_active:false num_chunks:0 morsel:fixed_morsel_queue empty:false} -> chunk_accumulate_0_0x1517d8256110(X) -> dict_decode_1_0x1517d83ca310(X) -> olap_table_sink_-1_0x1517d83cb210(X)]]: Cancelled: Cancelled by pipeline engine, reason: Cancelled: packet_seq 5 in PTabletWriterAddChunkRequest already process: BE:126303884

与业务端SQL报的错误一样,都是提示 reason: Cancelled: packet_seq 5 in PTabletWriterAddChunkRequest already process: BE:126303884

Canceled,有可能是超时了,只是这个版本,有时候没返回真实原因,把日志打包发下?