0、背景
有个Flink任务每天不定时会出现数据积压,无论是白天还是数据量很少的夜里,且积压的数据量会越来越多,得不到缓解,只能每日在积压告警后重启,重启之后消费能力一点毛病没有,积压迅速缓解,然而问题会周而复始的出现,无论是周末还是节假日忍不了。
一、现象
1:当积压时,最明显的是kafka积压不断升高
- Flink ProcessFunction(主要处理逻辑)中多个代码块处理时间变长:
为了定位问题,在processFunction多个代码块加了处理时间的计算,结果发现,无论是简单的json处理部分还是与外部Redis,Mysql交互部分,都会有执行时间久的记录,另外这个任务Sink的地方是神策接口,接口设置的有超时时间,所以也会看到很多Sink TimeOut的记录。
二、解决过程
2.1 排查过程
1.调整读取kafka消息数量:
ConsumerConfig.MAX_POLL_RECORDS_CONFIG,"300"
2.调整Sink端接口的超时时间等
- 调整任务资源
上面三个调整,前面两个没啥用,后面这个任务由原来一天一次不定时积压变成了2-3天积压。
虽然调整问题有所改善,但是还得找到真正的原因彻底解决,后面发现,当任务积压时,TaskManager所在的机器CPU会突然升高,且一直持续,直到任务重启。
2.2 问题解决
接下来就是分析CPU升高的原因,可以参考另外一篇博客线上java程序CPU占用过高问题排查_vioao的博客-CSDN博客_java程序cpu占用过高
去查看任务pid的一些相关信息,这里放两张图:
这么频繁的FGC,那问题就很明显了,FGC的时候,CPU升高,对应代码里CPU片段走到哪就停到哪,然后这一块的执行时间就变成,有的是5s,有的是15s
最后就是分析频繁FGC的原因,从上面第一张图也大概能看出来,ResultSetImpl是执行Mysql查询结果返回的对象类型,为了问题的排查,还是借助一下专业的工具
把内存文件dump下来分析一下。
排查代码,发现与外部Mysql交互的时候,前面开发的同学大意,没做close,好吧,加上吧。
java
finally {
if (rs != null) {
try {
rs.close();
} catch (SQLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
if (prepStatement != null) {
try {
prepStatement.close();
} catch (SQLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
if (conn != null) {
try {
conn.close();
} catch (SQLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
参考资料: