现在又开启 is_report_success 这个参数，需要看下sql执行上报吗
我理解那个是查询的明细，对目前帮助不大。
辛苦sudo perf top -p starrocks_pidfa发下这个截图吧。好像是死锁问题。
这个界面可以点击相应的行进入详细界面，可以看下第一行的详细信息么？
截图发出来了，是这样的吗
目前CPU还是没有讲下来？
只能重启be服务，才能降下来
只是用UDF CPU使用就很高吗
给BE配置一下GC日志
export LIBHDFS_OPTS="-Xloggc:$STARROCKS_HOME/log/be.gc.log.$DATE -server"
UDAF 做的路径分析，计算比较复杂的时候，sql查询超时之后CPU就不会释放了
这个现象是 full GC 了，你group by基数多大
2.3和main 解决了高基数 group by full gc的问题。2.2 不建议用 UDAF 处理太高基数的. UDF 应该是没问题
2.3 大概什么时候能发版呢
现在改了那个参数了，要复现一下CPU不释放的问题吗
你可以先在测试环境测一下2.3的高基数group by。这周应该会发rc版
你先看一下基数是多少
分组键 4000多
关了pipeline调整一下并行应该是能执行出来。
我们的pipline一起是关着的，因为之前测试发现，开着pipline执行结果不对，和社区的一个git账户叫sdtin的小伙伴沟通后，说是让关掉，就一直为false