YARN ResourceManager 进程异常退出问题追查

今天计算集群主节点异常退出的问题已经查清，是由异常job和yarn 调度bug造成。异常job的map数量高达十几万，将所有计算节点的本地磁盘几乎耗尽，造成3个计算节点dead，从而引起yarn schduler模块处理expire事件的bug，最终进程退出。

 下面描述一下整个事件的经过：

11-10 18:35:14 异常hive job提交

11-10 23:15:32 异常job完成前两轮计算，开始第三轮计算，也就是106954个map的job

11-11 07:15:12 计算节点hadoop094磁盘耗尽，dead。

11-11 07:22:34 计算节点hadoop064磁盘耗尽，dead。从11月11日凌晨至早上8点，集群所有计算节点的可用磁盘空间持续下降，下图是hadoop064的情况。

11-11 07:27:16 ResourceManager的NMLivelinessMonitor服务发现hadoop094已经10分钟没有汇报，将其状态设置为expire，交由RMNode状态机处理。这里不描述处理hadoop094超时事件的过程，下面会描述hadoop064超时处理过程。

11-11 07:33:56 ResourceManager的NMLivelinessMonitor服务发现hadoop064已经10分钟没有汇报，将其状态设置为expire，交由RMNode状态机处理。RMNode状态机抛出NodeRemovedSchedulerEvent事件和NodesListManagerEventType.NODE_UNUSABLE事件，然后获取RMActiveServiceContext的nodes容器，将hadoop064去除，获取inactiveNodes容器，将hadoop064加入其中，也就是在RMActiveServiceContext中标记了hadoop064不可用。NodeRemovedSchedulerEvent事件由FairScheduler处理，首先处理hadoop064上的container，逐个释放，然后把hadoop064从自己的nodes中删除。事情到这里是一个段落，如果没有遇到bug，结果就是整个集群磁盘打满，然后集群不可用，这里的不可用包括计算和存储。然而。。。。 我们的FairScheduler开启了continuous schedule功能，即FaireScheduler会开启一个线程ContinuousSchedulingThread，异步的分配节点上资源，分配的时候会拷贝FairScheduler的nodes对象。bug就发生在这里，异步调度时，拷贝nodes对象的时间点，正好FairScheduler在将hadoop064移除的时候，结果就是hadoop064实际上已经被移除了，但是还是被分配了资源给job。

11-11 07:33:56 hadoop064上被分配了job_1444323432870_195441的task，container_1444323432870_195441_01_003080

11-11 07:47:15 ContainerAllocationExpirer发现container_1444323432870_195441_01_003080 10分钟没有汇报，认为其expire。这是必然的，因为hadop064早就dead了。ContainerAllocationExpirer抛出ContainerExpiredSchedulerEvent事件。

11-11 07:47:15 ContainerExpiredSchedulerEvent事件由FairScheduler处理，处理的时候需要需要根据RMContainer获取RMNode信息，这个要访问FairScheduler的nodes对象，但是nodes里面已经没有hadoop064了，所以返回了null，后面的处理并没有考虑到null的情况，结果报出了NPE异常。

11-11 07:47:15 FairScheduler在处理container_1444323432870_195441_01_003080的expire事件遇到异常，ResourceManager进程退出，计算集群不可用。

 解决方案：

对NPE进行处理