云梯开发人员在云梯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调查还是性能问题，关键都在于定位原因，原因找到后解决才能确定解决方案。