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

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

看一下GC log用了多久呢

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

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

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

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

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

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

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

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

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

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

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

试了一下 您说的让udf的class加载一次的方法 确实真正的udf类只加载了一次 但是发现执行sql特别慢 timeout也没执行出来结果

有无使用的udf的 sql 都是执行不出结果 到达query_time 自动停止了

select 1; 也卡住吗，现在是哪个版本？

您的方法是有用的 我改了下代码 同事在new对象中有一些网络通信的逻辑 导致的问题 我移动到 静态代码块中 就没问题了 现在已经是您所说的 规避掉了类加载很多次的问题 还要继续观察几天

感谢您 真是帮了太大忙了 看您说的是临时规避这个问题 不知道后续会怎样

那看起来你们的问题就是UDF中某些操作导致class无法析构导致的了，可以观察一段时间以及GC日志，看看他这个内存使用还会不会涨上去

这种操作会导致不同的UDF之间失去了隔离性，后面新增UDF的时候依赖冲突可能会导致执行失败，后面可能会提供一种可以常驻但是还有一定隔离性的模式

好的 感谢您的 帮助 我们观察下集群的状态 有问题呢还需要向您群求帮助