hi，立志： 从你的描述（能跑 10 几天且使用的是 FsStateBackend），可以提供一下 JobManager 和 TaskManager 的 GC 时间和次数的监控信息吗？怀疑是不是因为 Full GC 导致的问题。
Best！ zhisheng 张立志 <[email protected]> 于2020年6月28日周日 上午10:13写道： > 从监控后台看back presure 是正常的，flatMap 这个任务是存在的，但只是连了一下mysql，没有别的任何操作，而且另一个job > 没有flatmap ,单纯的map reduce > 统计，能跑10几天，到1个多G的时侯就明显变慢，然后超时10分钟就报错了，从后台的错误日志里，没有明显的异常信息，都是checkpoint > 超时后的信息. > 在 2020-06-28 09:58:00，"LakeShen" <[email protected]> 写道： > >Hi 张立志, > > > >一般 Checkpoint 超时，可以先看看你的任务中，是否存在反压，比如 Sink 阶段，又或者是某个地方有 flatMap操作导致。 > > > >然后看下自己任务中，是否存在热点问题等。如果一切都是正常的话，可以尝试使用 RocksDB 的增量 Checkpoint ，具体参考[1]。 > > > >[1] > > > https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/state/state_backends.html#rocksdb-state-backend-details > > > >Best, > >LakeShen > > > >张立志 <[email protected]> 于2020年6月28日周日 上午9:52写道： > > > >> flink 版本1.8 > >> 部署集群yarn > >> > >> > >> 配置代码: > >> StreamExecutionEnvironment.stateBackend(new > >> > FsStateBackend("hdfs://nsstreaming/streaming/flink_checkpoint/state").checkpointingInterval(1000*60*10).checkpointTimeout(1000*60*10).timeCharacteristic(TimeCharacteristic.IngestionTime).build(); > >> 业务代码相对比较简单，内存占用较大 > >> 超过10分钟后开始报错，state 大概在1.5G时，开始耗时开始变长 > >> > >> > >> > >> > >> > >> >
