执行java udf函数 method request time out, please check 'onceTalkTimeout' property. current value is:60000(MILLISECONDS)

[U_1696990408248_3388]

sr集群是 3台fe 和 5台be 混部的，就是又3台的服务器既有fe也有be
服务器配置都一样如下

sr 完全安装再数据盘 /data下

fe最新的配置

be最新的配置

下面介绍怎么一点点修改集群jvm配置的

同事编写的java udf函数 功能是某个市的车辆经纬度数据，匹配行政区域的操作
数据来源表的ddl大致如下

每天的数据量大概如下

我们只对天的数据进行统计 有每5分钟统计从0点到当前全天的 和t+1 统计前一天的数据
主要就是利用经纬度数据传入此udf函数中反馈匹配的居于结果

最开始的时候配置fe 的jvm参数 从原始的 -Xmx8192m 变成了16384M
be没有添加任务jvm参数

当发现执行了一些此udf函数的sql的时候 会报错
exception happened when get class: java.lang.OutOfMemoryError: Compressed class space[] backend:172.28.203.232
和
rpc failed, host: 172.28.203.232

fe 和 be 会挂掉一两个

经过参考文章
(https://www.cnblogs.com/happyflyingpig/p/8886952.html)
(https://www.zhihu.com/question/268392125)
(https://www.jianshu.com/p/3e3903b5ca29)

当jvm的堆内存设置为 32G的时候，虚拟机就不用这个东西了Compressed class space
把 be 和 fe的jvm都调整为-Xmx32G 发现刚开始很不错，但是运行一段时间发现，内存累计增大，cpu和内存不释放导致 be和fe挂掉

继续调整参数发现

UseCompressedClassPointers
压缩类指针。对象的类指针（_klass）被压缩至32bit，使用类指针压缩空间的基地址
64bit服务器上设置-Xmx32g时，-XX:+UseCompressedOops和-XX:+UseCompressedClassPointers会失效，所以最大的堆设置为31g
-XX:CompressedClassSpaceSize 大小的设置也是有限制，因为压缩开关是受制于 32G，所以这个自然也是不能大于 32G，不过 hotspot 规定了这个参数不准大于 3G，所以这个参数其实是不能大于 3G。
因此既能享受64bit带来的好处，又避免了64bit带来的性能损耗

最终把 be 和 fe的jvm都加上
-Xmx31G -XX:+UseCompressedOops -XX:+UseCompressedClassPointers -XX:CompressedClassSpaceSize=3G

发现 集群运行非常良好和正常 cpu和内存 都会得到释放，fe 和 be 再也没有挂掉的现象

但是早上起来发现 执行udf函数的sql 还是会有挂掉的情况
sql执行结果还是rpc failed, host: 172.28.203.232
fe.warn.log的日志

fe.out日志

be.WARNING

grafana的监控信息 前24个小时的

一下是 top iotop pstack 信息
Desktop.zip (833.8 KB)

[许秀不许秀]

发一下版本号看看？

[U_1696990408248_3388]

[许秀不许秀]

你的UDF中会启动后台线程吗，这个可以排查一下，正常情况下UDF不会消耗这么高的内存。
这个OOM我怀疑是 class 对象被线程引用，导致class对象无法GC导致没有可用的内存了，我建议你配置下面的JVM参数:
JAVA_OPTS=“be.gc.log -verbose:class”
配置这个之后观察下 gc.log 和 be.out
be.out 里面期望有 Unload class 的字样

[U_1696990408248_3388]

好的我加上观察一下，但是 现在我配置的这个 -Xmx31G -XX:+UseCompressedOops -XX:+UseCompressedClassPointers -XX:CompressedClassSpaceSize=3G 已经没有oom的错误了 重点是 request time out, please check ‘onceTalkTimeout’ property. current value is:60000(MILLISECONDS) correlationId:879402 timeout with
这个问题，官网配置中并没有找到 onceTalkTimeout 的时间配置

[许秀不许秀]

你配置的这个参数应该是没有解决root cause，虽然没直接报告OOM，但是他GC时间太久导致BE没有响应，只是修改超时时间应该解决不了这个问题

[U_1696990408248_3388]

好的 我加上观察一下

[U_1696990408248_3388]

确实如您所说出现了 这样的日志

[许秀不许秀]

看一下GC log用了多久呢

[U_1696990408248_3388]

是这个吗 be的logs没出现 gc.log 文件 fe有这个日志文件 也要看fe的吗

[许秀不许秀]

gc.log 应该是在 启动BE的目录里面

[U_1696990408248_3388]

额 找不到 find / -name “gc.log” 都找不到 只有fe有

[许秀不许秀]

改一下参数，改成绝对路径

[U_1697159715924_2407]

昨天下午4点左右重启，现在查询又开始变慢了，这是当前9点半5台be的be.gc.log；
想了解下SR的udf的调用方式，我们因为想做geo的空间计算，所以在UDF种声明了空间索引，这个空间索引很大，设计全国区域的行政规划，做的RTree索引，存在了集合中。这个方法在hive中和flink中可以正常运行。这2种方式因为都是yarn管理，所以可以看到内存的占用，SR中会将我们创建的索引常驻在内存中么？

[许秀不许秀]

搜一下有FullGC吗，找一下不卡的时间点，这个老年代的内存使用是不是慢慢涨上去了？

[许秀不许秀]

默认情况下不会常驻内存，可以看一下你们加载的class有没有被Unload，另外看一下be的线程数量，是不是你们有线程仍然引用了这些class？

[许秀不许秀]

这个变慢是指因为并发上去了变慢还是单查询也变慢了

[U_1697159715924_2407]

普通查询，连建表语句都执行12S,FE挂了一台

[许秀不许秀]

可以试一下这个 如何让UDF的class只加载一次 ，我看这个Metadata Full GC，证明你的class应该是堆积了，这证明是你的class有其他引用的，这个应该能临时规避你的问题

[许秀不许秀]

class 没有GC掉的原因可能是后台线程或者是对class loader做了什么操作。可能需要具体分析你的UDF代码才能明确原因