Flink 1.8升级至1.15.2后TaskManager卡邮箱队列，吞吐量骤降求助

1. 排查邮箱队列阻塞核心原因 #

• 检查Kinesis Source与下游算子的并行度匹配：Source并行度设为8，但下游算子未显式指定并行度。Flink 1.15的默认并行度逻辑与1.8存在差异，若下游并行度远小于Source，会导致数据在Source输出队列积压，占满邮箱队列。建议给所有下游算子显式设置合理并行度（如与Source一致，或根据TaskManager资源调整）。
• 检查MyEvent对象的内存问题：Flink 1.8到1.15的内存模型变化较大，若MyEvent对象过大或存在未释放的引用，会引发频繁GC，导致线程阻塞、邮箱队列处理停滞。使用jmap、jstack分析内存占用，查看是否有大量MyEvent对象堆积。

2. 验证算子链与任务调度逻辑 #

• 尝试断开Source与下游算子的链：Flink 1.15默认开启算子链优化，若Source（IO密集）与下游计算密集型算子被强制链在一起，会互相阻塞。在Source后添加disableChaining()：

  final DataStream<MyEvent> kinesisStream = env.addSource(dataSourceFunction)
              .setParallelism(8)
              .uid("kinesis-source")
              .disableChaining();
  

• 检查Rebalance算子的适配性：Flink 1.15对Rebalance的负载均衡逻辑做了优化，若上游Kinesis流存在严重数据倾斜，Rebalance可能无法有效分散压力。可替换为rescale()或自定义分区器，同时确保Kinesis流分区数≥Source并行度。

3. 排查状态迁移与Connector兼容性 #

• 验证Savepoint迁移兼容性：虽然Source设置了UID，但Flink 1.8到1.15的状态序列化格式有较大变化，尤其是自定义状态类型。尝试不加载Savepoint直接启动新任务，排除状态加载导致的阻塞。
• 确认Kinesis Connector配置：Flink 1.15的Kinesis Connector包路径、参数名均有变更，检查dataSourceFunction是否使用1.15版本的Connector，shardIteratorType、maxRecordsPerPoll等参数配置是否合理，避免Source拉取数据过快但下游处理跟不上。

4. 调整线程模型与资源配置 #

• 优化TaskManager资源：Flink 1.15的TaskExecutor线程模型与1.8不同，调整以下配置：
  • 增大taskmanager.network.memory.fraction，扩充网络缓冲区，避免网络队列阻塞引发邮箱队列积压。
  • 匹配taskmanager.numberOfTaskSlots与CPU核心数，减少线程上下文切换频率。
• 扩容JobManager资源：JobManager吞吐量低可能是Checkpoint元数据、状态请求处理压力过大导致，调整jobmanager.memory.process.size增加堆内存，避免JobManager GC拖慢集群调度。

5. 细化日志与监控分析 #

• 开启细粒度日志：给org.apache.flink.runtime.taskmanager.Task、org.apache.flink.streaming.runtime.tasks.StreamTask设置DEBUG级别日志，查看邮箱队列的消息堆积、处理耗时等细节。
• 利用Flink UI指标：查看算子的numRecordsIn/numRecordsOut确认数据是否流入下游，查看mailbox.queue.size指标定位队列积压的具体环节。

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