本文主要是介绍YARN集群维护部分问题汇总,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
云梯开发人员在云梯Yarn集群的搭建和维护过程中做了许多工作,本文选择这期间部分较为典型的问题,通过对这些问题的分析和解决方案,为大家分享分布式系统问题调查的经验。
调查的问题
1. 2013年初引入社区0.23时,调查ResourceManager运行过程汇总突然挂掉的问题
现象:监控报警,线上运行的RM突然挂掉,RM异常日志如下,
2012-12-17 17:20:28,294 FATAL org.apache.hadoop.yarn.server.resourcemanager.ResourceManager: Error in handling event type APP_REMOVED to the scheduler
java.lang.NullPointerException
at org.apache.hadoop.yarn.server.resourcemanager.scheduler.SchedulerApp.unreserve(SchedulerApp.java:390)
at org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler.completedContainer(FairScheduler.java:590)
at org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler.removeApplication(FairScheduler.java:546)
at org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler.handle(FairScheduler.java:871)
at org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler.handle(FairScheduler.java:80)=
at org.apache.hadoop.yarn.server.resourcemanager.ResourceManager$SchedulerEventDispatcher$EventProcessor.run(ResourceManager.java:340)
at java.lang.Thread.run(Thread.java:662)
处理方法:启动RM继续提供服务,记录bug,开始调查。
调查过程:社区暂无此问题,需要自己分析。
a.分析,查看异常之前的代码,还发现一些其他异常,Error in handling event type NODE_UPDATE to the scheduler,RM的调度器处理Node更新的时候出现NPE,根据异常和代码判断出在AppSchedulable#assignContainer中 在reserved=true的情况下,获取的container的priority和传入的priority不一致导致的。通俗的讲,就是调度器有预订机制,另外在分配资源的时候每个container都有优先级,如果一个应用有在一个NM上预订一个优先级为X的container,另外一个等待的container优先级为更高的Y,当这个NM发生心跳给RM说,可以向它调度一个container,这时调度器本想找一个优先级更高的Y调度到该节点上,却没有找到,导致NPE。
解决方案:调度器应该优先找一个已经预订在该节点上的container分配给该节点,其次才是选择高优先级的container。不过就在我们调查出并解决的时候Apache Hadoop社区也刚好遇到并提供解决方案,因此最终没有贡献给社区。
2. 调查某些情况下RM不调度的问题
现象:RM能接收提交的作业,但是集群中所有作业都无法被调度,日志也没有异常。
调查过程:Dump出RM的进程栈,发现RM处于死循环状态。查看死循环部分的代码,原因是 调度器每次分配一个container给NM,然后对app排序,继续下一次的分配,如果调度器只是把container预订到该NM上,调度器没有调度任务给该NM,对app排序,进行下一次分配,这样就RM进入了死循环,无法工作。
解决方案:如果把某个container预订到NM上,也应该认为分配了相应的任务,退出循环。贡献给社区,YARN-300。
3. 调查RM异常退出的问题
现象:监控报警,线上运行的RM突然挂掉,RM异常日志如下:
2012-12-30 17:14:17,171 FATAL org.apache.hadoop.yarn.server.resourcemanager.ResourceManager: Error in handling event type NODE_UPDATE to the scheduler
java.util.ConcurrentModificationException
分析过程:异常是两个线程同时对一个对象进行操作,一个线程有加锁,另外一个线程没有加锁,导致异常的出现。
解决方案:两个线程都在调用该对象前加锁。贡献给社区,YARN-301
4. 调查网页上显示FairScheduler调度资源不准确的问题
现象:RM网页上显示调度信息不准确,资源使用量越来越大,已经超过集群资源量(内存)。
原因:reserve的时候增加三次,unreserve的时候减少两次,导致数字越来越大。
解决:reserve与unreserve应该相对应,增加多少就得减少多少。社区也有相应的问题,暂未贡献给社区。
5. 客户端提交作业后一直hang着,没反应
现象:用户提交一个作业到RM的某个组,但是RM上配置这个组不接受这个用户作业,这时候客户端一直hang这没反应。
原因:原因是以为RM判断出不允许的作业时,没有做如何处理,导致客户端一直hang着。
解决:增加处理机制,返回给客户端相应的出错信息。贡献给社区 YARN-319。
还有一些RM挂掉的问题,社区刚好解决,我们直接引入,如
https://issues.apache.org/jira/browse/YARN-335 RM出现NPE挂掉
https://issues.apache.org/jira/browse/MAPREDUCE-4144 RM处理Node更新的时候出现NPE
6. 引入Cgroup使Yarn支持对CPU的调度和隔离。
问题:Spark应用是内存密集型,但是对CPU要求不高,而MPI对CPU要求多,只有内存的调度不够。
设计:社区提供的Cgroup,支持CPU的隔离和调度。引入这部分后,我们遇到一个比较严重的问题,它要求NM创建账户,这从运维角度上来说是不可行的,它的目的是为了安全性,但是对内部应用来说必要性不大,另外Cgroup对CPU的隔离不依赖多账户,因此通过修改一个container-executor.c,防止启动container的时候修改账户,而是使用一个统一的账户运行container,即能满足安全需要,又能减少运维人员的工作量。
7. MRApplicationMaster初始化性能优化
问题:MRApplicationMaster初始化很慢。
分析:通过调查发现慢在解析rack上,由于集群大,datanode多,MRApplicationMaster启动的时候会初始化map task,这时候会频繁调用解析脚本,导致初始化慢,严重影响作业的运行时间
解决方案:通过在每个NM上增加一个包含所有datanode的机器名和rack对应信息的文件,MRApplicationMaster启动的时候读取这个文件,防止频繁调用解析脚本,大大加快了作业初始化速度。
经验总结
Hadoop类似的分布式开源框架,出问题还是比较常见的,关键是出问题后如何解决,
a. 一般情况下首先到社区寻找类似的问题,如果已经解决则直接引入即可
b. 如果社区没有解决,那么就需要自己分析,如果是bug问题,则需要通过分析日志和代码,最好能在测试集群上重现相应的问题,若能重现,则通过远程调试或增加打印日志的方式分析相应的问题。找到原因后解决方案则是多种多样的,要结合自己的实际情况选择解决方案。
c. 如果是性能问题,则需要分析性能瓶颈,慢在哪一块,慢在哪一步,慢在哪行代码,多向自己提出这几个问题,则能一步步的定位性能瓶颈,然后就需要创新性的提出一些优化方案。
所以在分布式应用中,无论是bug调查还是性能问题,关键都在于定位原因,原因找到后解决才能确定解决方案。
这篇关于YARN集群维护部分问题汇总的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!