starrocks catalog表与内表关联查询超时900s

[sunshangshang]

为了更快的定位您的问题，请提供以下信息，谢谢
【详述】starrocks catalog表与内表关联查询超时900s
【背景】新增物化视图
【业务影响】影响生产查询
【是否存算分离】否
【StarRocks版本】3.1.12
【集群规模】3fe+3be 混合部署
【机器信息】CPU虚拟核/内存/网卡，例如：48C/64G/万兆
【联系方式】v：sun7891011
sr 3.1.12, 内表与jdbc catalog表关联查询，有的时候秒出，有的时候查询900s超时被Kill,这个有什么排查思路吗，日志没看出什么问题

报错截图:

[sunshangshang]

单表查询也会oracle外表也会出现这个问题

[Star_Cao]

session 级别的query_timeout设置大一些，然后打开session级别的query_profile。执行sql，获取执行慢的时候的profile发一下

[sunshangshang]

简单的一个查询，设置了1h，报错了，profile见附件profile.txt (12.7 KB)

[sunshangshang]

在咨询下啊，有一个be节点的cpu使用比较高， 可能是啥原因导致的？

[Star_Cao]

需要看一下oracle主机到sr主机的网络联通性。当前看耗时主要在oracle端数据扫描这里。

[Star_Cao]

be cpu高，看一下消耗高的sql

[sunshangshang]

在哪里看啊，be日志看不出啥，目前只有访问catalog表和外表才会卡

[sunshangshang]

不是一直超时的，也有毫米级查询出来的。

[sunshangshang]

资源使用截图：

[sunshangshang]

这个是正常查询的profile正常profile.txt (10.9 KB)

[Star_Cao]

正常查询的耗时也是在读取oracle表这里。可以在oracle的监听日志看一下当前ip连接过去是否是正常的

[sunshangshang]

方便加下微信吗，新建的catalog，稳定复现，不存在网络问题，集群内的数据库

[sunshangshang]

可能是元数据挤压了吗或者元数据问题吗，因为不是每次都慢，有时候也是秒出

[sunshangshang]

starrocks集群和pg的catalog是在同一个网络内的，starrocks是不是有哪些线程数堵塞了？

[Star_Cao]

3.1版本的jdbc catalog不支持oracle。建议升级到3.2及以上版本

[sunshangshang]

没有使用oracle catalog啊。用的pg的，oracle用的是外表

[Star_Cao]

外表查询如果效率不满足要求或者出现性能跳变，将外表数据导入内表，转换成sr内部关联。