一、背景

系统：linux centos7.4
Yarn：3.0.0-cdh6.3.2

二、现象

业务方通知，大部分使用yarn的任务都长时间处于执行中的状态。

三、问题排查

查看yarn的ui发现，memory reserved的值，已经和memory total等值了。
然后查看applications的任务列表发现，其中两个任务的reserved资源非常大。

集群资源总量56G，这俩任务的reserved值已经达到56G了。

四、原因

reserved原理：
当所需的container的资源，在当前nodemanager无法满足的时候，yarn就会将nodemanager上的当前剩余资源预留起来，等其他进程释放资源后，合起来的资源足够这个container启动时，才会启动当前container。

1、查看内存分配
这两个任务需要的资源非常大，由于map和reduce的内存设置是0（cdh默认根据container所需内存量自动分配内存大小），所以在map和reduce每个container所需内存较大（本案例是卡在map阶段），并且由于container数量多，每个节点上都有这样的container。而根据reserved原理，所有节点上，都会等待资源你释放。
2、查看机器资源
通过free查看当前机器剩余可用内存，基本都只剩余2-3G的可用资源。

所以，可以判断，当前map分配的每一个container大小都在3G以上，甚至更大。nodemanager一直没有足够的资源释放，而且由于数量很多，container分布在每个节点，将每个节点8G的内存都预留了。最终导致整个集群卡在这两个任务上。

五、解决

1、临时解决：
将这两个任务杀掉，让后续的任务可以继续执行。但是问题是，后续这个任务在执行的时候，仍然会造成集群hang住。
2、根因解决：
根因就是集群资源不足。由于这个集群之前遇到过资源问题，当前恰好处于资源申请期，所以解决的根本办法就是资源扩容。保证每个container都有足够的空余内存来执行。

六、反思与规避

资源扩容的原因，其实就是没有做好资源规划。
而资源规划这一步可能出现的问题如下：
1、没有做好资源使用量的预估。比如数据存储、数据计算，尤其是中间结果数据的存储和计算，很有可能造成用量估计不足。
2、没有做时间窗口的预估。比如理应预估3年的总用量，但是只估了1年的，但是1年快到期的时候，没有提前做资源扩容计划。导致出现问题。
3、客户限于预算，无法提供足够的资源。这一步很难解决，钱是核心。如果预算是在不足，首先要跟客户报好风险；其次需要根据预算评估合理的受限资源；然后需要根据受限资源和任务、数据量来评估大数据集群各参数的配置，做到最优配置，以及可以将任务在时间维度上分散，避免高峰压力，通过种种手段，避免资源不足带来的风险。

好记性不如赖笔头。
与君共勉。