【StarRocks-异常咨询】

[ikun]

【问题咨询】
StarRocks 是因为什么原因导致以下异常？我们上了资源隔离，发现资源隔离有以下几个问题。

1、CPU是软隔离，导致无法更好的分配各个业务系统的资源限制，根据官网资源隔离介绍：如果当前 BE 节点资源非满载，则各个资源组能分配的资源是资源的总资源，但是满载的时候又是分配的是具体设置的资源组限制。

2、每个资源组我理解也是相对独立，互不影响，但是我们在实际使用的时候发现，如果A资源组使用率过大，B资源组会查询不动，有些简单的小查询也会报错SQL超时。

在我们最近的异常发现如下几点，发现业务的一个大查询导致其它业务查询不动的情况，实际CPU内存还有空闲剩余，为什么会发生这种情况？

A、2024年1月22日09:00:00 - 2024年1月22日10:00:00 开始大批量SQL超时报错，查看监控FE、BE内存监控正常。当时是运行一个查询SQL大概是15s左右（以前是正常是3-4s），最后重启整个FE+BE后恢复。

B、2024年1月22日11:37:00 - 2024年1月21日11:40:00 有部分业务报错SQL超时，查看fe.audit.log，发现查询被取消。

C、另外关于StarRocks监控，这两个监控是有问题吗？

【StarRocks版本】2.5.8
【集群规模】3fe+10be（fe与be混部）
【机器信息】：96C/256G/万兆

[jingdan]

查询性能波动，
1.确认磁盘io、内存和cpu资源是否足够，截图
2.确认是否达到资源分类器的限制
3.慢和快的profile，explain costs + sql

[ikun]

1、查看监控CPU、内存资源都是正常的，虽然说是有波动，但是并没有打满。

2、查看资源组确实有波动，但是不至于跑不动，报错SQL超时

3、当时没有保存到explain sql分析，我们下次出现这种情况的时候可以保存起来给到官方排查。

另外我们这两天还经常出现以下报错，这种情况是什么原因？

StarRocks planner use long time 3000 ms in memo phase, This probably because 1. FE Full GC, 2. Hive external table fetch metadata took a long time, 3. The SQL is very complex. You could 1. adjust FE JVM config, 2. try query again, 3. enlarge new_planner_optimize_timeout session variable

[jingdan]

@ikun

StarRocks planner use long time 3000 ms in memo phase, This probably because 1. FE Full GC, 2. Hive external table fetch metadata took a long time, 3. The SQL is very complex. You could 1. adjust FE JVM config, 2. try query again, 3. enlarge new_planner_optimize_timeout session variable

这个问题拿下 query dump

[jingdan]

另外fe的gc日志也发下