一、背景
系统: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、客户限于预算,无法提供足够的资源。这一步很难解决,钱是核心。如果预算是在不足,首先要跟客户报好风险;其次需要根据预算评估合理的受限资源;然后需要根据受限资源和任务、数据量来评估大数据集群各参数的配置,做到最优配置,以及可以将任务在时间维度上分散,避免高峰压力,通过种种手段,避免资源不足带来的风险。
好记性不如赖笔头。
与君共勉。