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