你好， 1. TM MetaSpace OOM应该是由于你反复提交job造成的。反复提交作业可能导致短时间内Class和UserClassLoader过多并且无法被及时回收。 2. TM OOM导致不能及时发送心跳给JM就会因为超时让JM认为TM下线。理论上OOM了是会自己退出进程的。 3. 如果不能将集群部署到Kubernetes或者yarn下的话，建议可以通过JM的API监控下TM数量，如果TM数量下降可以做些运维操作。下面的link是一个JM api的介绍: https://nightlies.apache.org/flink/flink-docs-master/docs/ops/rest_api/
> On 18 May 2022, at 10:45 AM, 知而不惑 <chenliangv...@qq.com.INVALID> wrote: > > 请问大家一个问题， > 场景： > 版本是Flink 1.14 > 我们使用standalone 模式，我们的Flink job由supervisorctl托管，JM和TM用systemd托管 > > > 异常： > job异常重启设置了两次的flink延迟重启：restart-strategy.fixed-delay.attempts: 2， > 我们线上有个业务代码没有捕获一个异常，导致job重启两次后，再由supervisorctl重新提交job，循环了很多次之后， > TM出现了元空间OOM(我们已经把元空间的内存加大，还是会出现)，然后TM就掉了，控制台上没有TM了，这影响了其他的job，但是TM进程也没有退出，我们的TM由Systemd托管，所以TM一直没有重启， > 处在一个“假死”状态，我们是用的standalone模式，只有一个TM， > > > 日志： > TM日志出现：TM metaspace oom > JM日志：Association with remote system [akka.tcp://flink@localhost:43583] has > failed, address is now gated for [50] ms. Reason: [Association failed with > [akka.tcp://flink@localhost:43583]] Caused by: [java.net.ConnectException: > Connection refused: localhost/127.0.0.1:43583] > JM 连接 TM接口失败，unreachable > > > > 补充： > 我们把元空间内存配置放到512M。再次重现： > 发现每次提交job的时候： > 观察tm metaspace 内存变化：179MB 183MB 207MB 232MB 256MB > 280MB 352MB 372MB > 元空间一直没回收，这样最终会导致TM metaspace oom > > > > 问题： > 1.想问下TM元空间oom异常，是反复提交job造成，还是job的业务代码有问题， > 2.TM元空间OOM为什么会导致JM认为TM掉线，TM也不自己退出进程 > > > 希望获得的帮助： > 1.上述问题原因 > 2.有什么办法可以在standalone模式下，识别到TM掉线，从而我们能做一些自动的运维操作：比如重启整个集群
