这个问题比较奇怪，我尝试加大了task.offheap的内存，主要是为了加大 direct memory 的限制，部分作业加大后ok了。 今天又发现一个作业，direct mem 达到9G了还不行（5G task.offheap额外配置，另外4G是network部分配置的，所以jvm参数部分对direct mem的限制是9G）。
Yuxin Tan <tanyuxinw...@gmail.com> 于2023年5月26日周五 18:15写道： > > hi, yidan > > 除 jvm 参数外，flink 其他配置完全一样吗？比如 state backend 是否有变化？ > > 另外， jdk11 是不是用的最新版本，不是的话，觉得也可以尝试一下最新版本。 > > 如果 jdk11 用的最新版本，可以尝试下使用其他 GC 算法是否也有同样问题。比如 -XX:+UseParallelGC > -XX:NewRatio=3 -XX:ParallelGCThreads=4 -XX:CICompilerCount=4 > -XX:-CompactStrings > > Best, > Yuxin > > > yidan zhao <hinobl...@gmail.com> 于2023年5月26日周五 17:39写道： > > > 最近升级flink版本和jdk版本，flink从1.15.2升级到1.17.0，jdk从8升级到11。然后出现大量full gc。 > > 分析后，发现主要是 System.gc() 导致。 进一步定位到是 redisson 库中 netty 部分用到了 DirectMemory > > 导致。 直接内存不足，导致频繁调用 System.gc 触发 full gc。 > > 我现在问题是，通过测试对比实验发现，jdk8+flink1.17没问题，jdk11+flink1.17就会有该问题。 > > 有人知道原因嘛？ > > > > 其他信息： > > > > jdk8和jdk11情况下都是G1GC，且vm参数一致，直接内存max限制也一致。但是通过jinfo等查看，确实jdk8场景下的directMemory使用较少。 > >
