记一次Flink 消费Kafka数据积压排查解决

  接手了一个问题排查的工作，有个Flink任务每天不定时会出现数据积压，无论是白天还是数据量很少的夜里，且积压的数据量会越来越多，得不到缓解，只能每日在积压告警后重启，重启之后消费能力一点毛病没有，积压迅速缓解，然而，问题会周而复始的出现，无论是周末还是节假日，忍不了。

 1：当积压时，最明显的是kafka积压不断升高

2. Flink ProcessFunction（主要处理逻辑）中多个代码块处理时间变长

        为了定位问题，在processFunction多个代码块加了处理时间的计算，结果发现，无论是简单的json处理部分还是与外部Redis，Mysql交互部分，都会有执行时间久的记录，另外这个任务Sink的地方是神策接口，接口设置的有超时时间，所以也会看到很多Sink TimeOut的记录

1. 调整读取kafka消息数量

ConsumerConfig.MAX_POLL_RECORDS_CONFIG,"300"

2.调整Sink端接口的超时时间等

3. 调整任务资源

上面三个调整，前面两个没啥用，后面这个任务由原来一天一次不定时积压变成了2-3天积压

问题还是要解决的，彻底解决的

其实一直没找到真正的原因

后面发现了，当任务积压时，TaskManager所在的机器CPU会突然升高，且一直持续，直到任务重启

好吧，这里就是最终的决赛场了

接下来就是分析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();
        }
      }
    }

太不容易了，这么一个小问题折磨了前面同事这么久，到此结束。