记一次 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)
所以基本可以断定,这个Flink作业在向HDFS写文件花了太多时间(5分钟)。那这个时间是正常的吗?我们找了一下此前启动这个任务的日志,发现当时这一步就快很多,一分多钟就完事了。
所以应该是HDFS变慢了,测试一下上传个文件看看:
发现传输一个23GB的文件需要10分钟左右。
再看下集群负载,都是正常范围以内,与此前持平,其他作业也无异常。
HDFS慢的原因可能和集群负载、集群小文件过多、网络、磁盘故障、namenode请求负载等等有关系。根据之前经验,太久没有重启集群HDFS也会变慢。因为排查集群各个方面都正常,所以计划使用重启大法 :)
再重启之后再尝试HDFS上传文件测试,发现明显快了很多了,同样一个23GB的文件现在只需要1分多钟。
本文的重点主要在于如何判断Flink作业卡住原因,如有错误,欢迎指正。