数据处理和 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
扫码关注腾讯云开发者
领取腾讯云代金券
Copyright © 2013 - 2025 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号:粤B2-20090059 深公网安备号 44030502008569
腾讯云计算(北京)有限责任公司 京ICP证150476号 | 京ICP备11018762号 | 京公网安备号11010802020287
Copyright © 2013 - 2025 Tencent Cloud.
All Rights Reserved. 腾讯云 版权所有