apachebeam的2.28.0javasdk正与flinkrunner一起用于我们的管道。我们有两条管道：
kafka源->转换->使用固定窗口聚合->cassandra接收器
Kafka源头->转型->Cassandra汇
在这两个管道中，对高内存消耗的观察结果是相似的。使用的部署平台是kubernetes。
在内存优化练习期间，提供了精确的任务管理器内存配置，以确保容器内存不超过任务管理器的总进程内存。https://ci.apache.org/projects/flink/flink-docs-release-1.12/deployment/memory/mem_setup_tm.html 这是提供的配置：

这是任务管理器pod中的jvm调试日志：

如您所见，heap/nonheap/direct内存处于控制之中。
现在，奇怪/错误的部分是容器内存在不断增加，并且超过了总进程内存：

而且，用户代码非常简单，为了证明用户代码中没有问题，在原生flink sdk上构建了相同的管道。指数级的记忆增长已经消失了，而且已经得到了很好的控制。
使用完全相同的业务逻辑检查本机flink的配置：
taskmanager.memory.process.size:800m taskmanager.memory.flink.size:570m taskmanager.memory.task.heap.size:200m taskmanager.memory.task.off-heap.size:50m taskmanager.memory.managed.size:0m taskmanager.memory.jvm-metaspace.size:130m taskmanager.memory.jvm-overhead.min:20m taskmanager.memory.jvm-overhead.max:320m taskmanager.debug.memory.log:false env.java.opts.taskmanager:“-xms300m-xmx328m”
此外，任务管理器吊舱内存使用稳定，并遵守配置设置的边界：