记一次 Flink 作业启动缓慢

记一次 Flink 作业启动缓慢

背景

应用发现，Hadoop集群的hdfs较之前更加缓慢，且离线ELT任务也以前晚半个多小时才能跑完。此前一直没有找到突破口所以没有管他，推测应该重启一下Hadoop集群就可以了。今天突然要重启一个Flink作业，发现有一个过程卡了五分钟。

现象

由上图可知09:36到09:41这两个过程中间花了五分钟，这两条都是Flink的日志，所以推测中间是Flink的某些过程卡住了。那Flink中间做了什么呢？

原因分析

可以看到这两条日志都是由flink同一个类所打印的：org.apache.flink.yarn.YarnClusterDescriptor ，所以去看下这个类的源码就知道了。
我们找到Flink源码的这个类org.apache.flink.yarn.YarnClusterDescriptor ，发现卡住之前的那条日志，也就是09:36那条日志，是由下面这条代码打印。

我们在看下 09:41 的那条日志是怎么打印的，我们找到了下面这个方法

看下在哪里调用了这个方法：

而正是startAppMaster这个方法调用了removeLocalhostBindHostSetting

现在我们再看下第一条日志代码位置

可以得出一个结论，卡住的代码是startAppMaster 方法从开始执行到调用 startAppMasterremoveLocalhostBindHostSetting 这个方法中间的那些代码，那我们可以看下这中间代码在做什么操作。
发现基本都是在调用YarnApplicationFileUploader 这个用于上传文件到YARN应用程序staging目录的工具类在往HDFS上传Flink作业所需的jar包或者配置文件。

final YarnApplicationFileUploader fileUploader =
                YarnApplicationFileUploader.from(
                        stagingDirFs,
                        stagingDirPath,
                        providedLibDirs,
                        appContext.getApplicationId(),
                        getFileReplication());

        // The files need to be shipped and added to classpath.
        Set<Path> systemShipFiles = new HashSet<>(shipFiles)
1
2
3
4
5
6
7
8
9
10

所以基本可以断定，这个Flink作业在向HDFS写文件花了太多时间（5分钟）。那这个时间是正常的吗？我们找了一下此前启动这个任务的日志，发现当时这一步就快很多，一分多钟就完事了。

所以应该是HDFS变慢了，测试一下上传个文件看看：

发现传输一个23GB的文件需要10分钟左右。

再看下集群负载，都是正常范围以内，与此前持平，其他作业也无异常。

HDFS慢的原因可能和集群负载、集群小文件过多、网络、磁盘故障、namenode请求负载等等有关系。根据之前经验，太久没有重启集群HDFS也会变慢。因为排查集群各个方面都正常，所以计划使用重启大法 ：）

再重启之后再尝试HDFS上传文件测试，发现明显快了很多了，同样一个23GB的文件现在只需要1分多钟。

本文的重点主要在于如何判断Flink作业卡住原因，如有错误，欢迎指正。