是的，不过刚刚那个不全be.out (1.9 MB) 这个是全部的
我们这边暂时有人再用这个集群做查询，刚刚重启了一下集群，暂时恢复了一下查询
请问下，咱们是测试集群么？能否帮忙验证下？目前猜测是自定义UDF的问题
重启后仍然使用了自定义UDF么？
有使用自定义函数的情况
现在又开启 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 大概什么时候能发版呢