0、背景

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

一、现象

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

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

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

 二、解决过程

2.1 排查过程

1.调整读取kafka消息数量：

ConsumerConfig.MAX_POLL_RECORDS_CONFIG,"300"

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

3. 调整任务资源

上面三个调整，前面两个没啥用，后面这个任务由原来一天一次不定时积压变成了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，好吧，加上吧。

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();
				}
			}
		}

参考资料：

1.《Flink 消费Kafka每日不定时积压（非重启不能解决）问题排查解决》