Flink TaskManager运行3个月后崩溃、Checkpoint超时失败如何解决？

该故障核心是Flink TaskManager的网络内存完全耗尽导致的处理链路阻塞：

• 报错栈显示任务卡在网络缓冲区回收逻辑，结合缓冲区使用率100%的监控，说明Network Buffer池被占满，任务无法申请新的缓冲区处理数据，整个数据流完全卡住
• 数据处理阻塞后Checkpoint barrier无法正常流动，导致Checkpoint在2分钟内无法完成超时失败
• 任务触发取消逻辑后也因为阻塞无法响应取消信号，最终触发超时导致TaskManager进程崩溃
• 平稳运行3个月后才爆发问题，大概率是业务数据量持续上涨、或者出现热点key数据倾斜，超过了现有配置的承载能力

先快速恢复业务，避免故障持续影响：

• 临时将Checkpoint超时时间调大到10分钟，避免连续Checkpoint失败触发任务重启：

  execution.checkpointing.timeout: 600000
  

• 调大TaskManager网络内存配额，当前配置是128MB，临时调整为512MB，缓解缓冲区耗尽问题：

  taskmanager.memory.network.min: 512mb
  taskmanager.memory.network.max: 512mb
  

• 重启任务恢复线上业务

1. 解决数据倾斜问题
   你当前任务使用了带精确去重COUNT DISTINCT的15分钟滑动窗口，是倾斜高发场景：

• 从Flink UI查看每个子任务的接收数据量、处理延迟，确认是否存在少数子任务处理量远高于其他节点的倾斜情况
• 如存在热点key倾斜，给热点key增加随机前缀，完成第一阶段聚合后再去掉前缀合并结果，打散热点压力

2. 优化计算逻辑降低负载

• 如业务允许近似去重，将精确COUNT DISTINCT替换为HyperLogLog或者BloomFilter实现，大幅降低计算和内存开销
• 15分钟大小、1分钟滑动的窗口会让每条数据被重复计算15次，如业务可接受调整，适当调大滑动步长降低计算频率

3. 网络缓冲区参数优化

# 调大每个通道的专属缓冲区数量，应对突发流量
taskmanager.network.memory.buffers-per-channel: 8
# 调大浮动缓冲区数量，让负载高的子任务可以申请到更多缓冲区
taskmanager.network.memory.floating-buffers-per-gate: 32

4. Checkpoint性能优化

• 如使用RocksDB状态后端，开启增量Checkpoint，大幅减少每次Checkpoint需要传输的数据量：

  state.backend.incremental: true
  

• 开启非对齐Checkpoint，适配反压场景下的Checkpoint加速，你使用的Flink 1.13版本完全支持该特性：

  execution.checkpointing.unaligned: true
  

5. 资源扩容
   如果确认是整体数据量上涨超过现有集群承载能力，对应提升任务并行度，或者调大TaskManager的CPU、内存配额，提升整体处理能力。

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