Flink1.11.2运行于EMR6.2.1时TaskManager心跳超时问题咨询

调大JobManager内存可以解决你遇到的两类TaskManager心跳超时问题——你当前给JM配置的2048MB内存，完全匹配不上180并行度作业的运行要求，是故障的核心诱因。

你当前作业并行度180，单TaskManager配4 slot，总共需要45个TaskManager运行。Flink 1.11.2版本中，JobManager的堆内存需要承载Task调度、所有TM的心跳请求处理、Checkpoint元数据协调、作业状态跟踪等核心逻辑：

• 你配置的2048M JM内存，扣除默认的元空间、堆外内存、JVM运行预留开销后，实际可用的业务堆内存仅1.2G~1.4G
• 作业启动阶段，JM需要同步处理所有Task的部署请求、资源分配应答，内存不足会频繁触发Full GC，GC停顿时间超过默认50s的心跳超时阈值时，就会判定TM失联触发重启，直接拉长启动时间
• 作业长期运行时，Checkpoint元数据、TM上报的状态信息会持续占用堆内存，运行20小时左右内存占用达到阈值触发长GC，就会再次出现心跳超时、Checkpoint失败的问题

• 首次调整直接将jobManagerMemory从2048提升到8192（8G），不要以1G/2G为小步进调试，浪费测试时间。该配置下扣除固定开销后JM可用堆在6.5G左右，完全可以支撑你当前集群规模、200以内并行度作业的长期稳定运行
• 如果你的作业单Checkpoint状态大小超过100G、Checkpoint间隔小于1分钟，可以再将JM内存上调到12G即可，16G以上的配置对你当前规模属于冗余配置，没有必要
• 调整后建议给JM追加JVM参数-XX:InitiatingHeapOccupancyPercent=35，让G1垃圾回收器在堆占用35%时就启动混合回收，避免堆占用过高触发长STW停顿

• 调整Yarn集群配置yarn.nodemanager.delete.debug-delay-sec为86400（即24小时），故障退出的TaskManager容器日志会在节点保留24小时，不会被立即删除，方便后续排查问题
• 内存调整到位前不要盲目调大heartbeat.timeout参数，最多将该值从默认50s调整到100s作为兜底，阈值过大会导致TM真实故障时JM无法及时感知，拉长故障恢复时间
• 调整后观测JM的GC指标，稳定运行时Full GC次数应为0，单次Young GC停顿控制在200ms以内即为正常，此时作业启动时间可以压缩到3分钟以内，不会出现启动阶段反复重启的问题，长期运行的Checkpoint成功率也会恢复正常

内容的提问来源于stack exchange，提问作者Nick