【Hadoop】【Yarn】ResourceManager频繁主备倒换，导致Yarn上作业大量积压

【问题描述】

MRS集群中，Yarn服务的ResourceManager实例频繁发生主备倒换。导致作业积压。

ResourceManager主备倒换虽然不至于造成断服，但是由于备实例升到主的时候需要额外启动一些服务，因此呛到主的ResourceManger实例实际上一段时间之内依然不能有效提供服务。因此ResourceManager主备倒换在现网中依然是一个重型操作。

【原理分析】

分析问题之前首先回顾下ResourceManager控制主备的原理。

ResourceManager两个实例在启动时候会创建一个名为ActiveStandbyElector线程。该线程会尝试在Zookeeper上面创建一个znode，路径为：/yarn-leader-election/yarncluster/ActiveBreadCrumb。创建成功的ResourceManager实例会将自己的主机名写入到该Znode中。写入成功意味着该ResourceManager实例抢主成功，另一个ResourceManager则会以standby的方式启动（Active ResourceManager和Standby ResourceManager进程中启动的服务不同）。

ResourceManager经历上面的抢主过程启动成功之后，其上ActiveStandbyElector仍然会持续监控Zookeeper上的节点：/yarn-leader-election/yarncluster/ActiveBreadCrumb，由于该ZNode的创建方式为EMPHERMAL，意味着如果客户端和该znode连接发生异常，那么该节点会被zookeeper自动删除，这样ActiveStandbyElector线程会进入下一轮抢主，优先创建znode成功的ResourceManager升为主节点。

【定位过程】

了解了上面的ResourceManager主备机制之后，下面分析下ResourceManager的日志。查看主备倒换相应时间段的ResourceManager日志，可以看到下面的日志片段：

从上面的日志中不难看出由于客户端长时间连接Zk超时，于是断开连接（zookeeper会在断开连接之后删除znode：/yarn-leader-election/yarncluster/ActiveBreadCrumb），备节点抢主成功，因此会触发一次主备倒换。

那么问题来了：为什么ResourceManager连接zookeeper超时？

排除了网络因素之后，接着分析下Zookeeper日志，发现该时间段内zookeeper频繁full gc。于是查看zookeeper的GC_OPTS参数，发现堆外内存和永久带内存只有64MB。于是修改zookeeper的GC参数，将堆外内存和永久代内存从64MB修改为256MB

【解决方案】

增加对外内存和永久代内存（根据实际情况而定，本案例汇总，最大堆内存够用，不用调整）：

MaxNewSize=256M

MaxMetaspaceSize=256M