【并发查询】并发查询性能下降

[飘过的小熊]

为了更快的定位您的问题，请提供以下信息，谢谢
【详述】同一个查询，起10个并发查询和单次查询，性能差距大
【背景】查基础表
【业务影响】
【是否存算分离】是
【StarRocks版本】例如：3.1.5
【集群规模】例如：1fe（8CU）+3be(16CU)
【机器信息】阿里云emr
查询语句

SELECT  old_goods_name
       ,COUNT(*)
FROM dim.dim_goods_mapping
WHERE load_date = '20240510'
GROUP BY  old_goods_name

并发查询超过3s

单次查询 0.3s

我拿了之前的 profile 分析，发现这个指标有差距 OutputFullTime ，不知道这个指标能怎么控制
636bc95e-0e9c-11ef-92ff-ca29426217d7-profile.txt (34.2 KB) 5753bce9-0e9b-11ef-92ff-ca29426217d7-profile.txt (34.1 KB)

[cpolive]

我100多个并发的时候show full processlist time 吓人

手动执行的时候毫秒级别的

[飘过的小熊]

我的场景也是 100并发压测过不了，我就来慢点点的分析，，发现好像分析不动了

[cpolive]

SQL很简单啊，也没有优化空间了，就只能看看社区大佬，参数有没有可以调整的
还有机器本身CPU/内存/IO使用率非常低
尝试调整：parallel_fragment_exec_instance_num，CPU一半，好像也没啥效果

[飘过的小熊]

大佬，我好像把我的这个场景分析出来了，主要是和返回查询结果数量有关

SELECT  old_goods_name
       ,COUNT(*) as cnt 
FROM dim.dim_goods_mapping
WHERE load_date = '20240510'
GROUP BY  old_goods_name
order by cnt 
limit 3,10

要是这样的话并发就会好很多，这也解释了为什么会卡在 result_sink ，在最后一个 fragment 里面有个 OutputFullTime 指标有问题

[cpolive]

我可能不一样，是 show processllist 跟fe.audit里面的查询时间都非常大，手动执行比较快
负载看SQL执行的时候，很低。。