数据处理和 barrier 处理都由主线程处理,如果主线程处理太慢(比如使用 RocksDBBackend,state 操作慢导致整体处理慢),导致 barrier 处理的慢,也会影响整体 Checkpoint 的进度,在这一步我们需要能够查看某个 PID 对应 hotmethod,这里推荐两个方法: 1、 多次连续 jstack,查看一直处于 RUNNABLE 状态的线程有哪些; 2、使用工具 AsyncProfile dump 一份火焰图,查看占用 CPU 最多的栈;
只需要指定检查点路径重启任务即可
bin/flink run -s :checkpointMetaDataPath [:runArgs]
checkpointMetaDataPath : 这个是检查点元数据路径,并不简单是所配置的检查点的路径
参考:https://blog.csdn.net/lt793843439/article/details/89641904
1、找出作业对应的jobID 2、进入hdfs对应目录,找到目录下面最新的检查点目录 3、通过指定检查点目录的方式重新启动作业 4、观察作业运行情况,如果出现内存溢出异常断开,加大内存重新启动。待作业运行稳定,查看作业最初异常中断的原因,记录下来并总结思考如何解决和避免。
在log4j或者logback的配置文件里单独指定org.apache.flink.runtime.checkpoint.CheckpointCoordinator的日志级别为WARN