Yarn中container、mr内存的配置，控制container个数_hadoop yarn 修改 container 队列数量

最近项目在用kylin，在搭建开发环境和测试环境后，然后在kylin上建cube，kylin建cube实际就是调用集群的MR跑任务(也可以调用spark作为引擎)，在数据量小或者维度(kylin里面的一个概念)少的时候没问题，后来数据量大或维度多了，就经常出现OOM的问题。

  其实一开始就知道是并行度过高的问题，也尝试过在kylin里面调试，但并没有用。后来通过jps查看yarnchild个数，再到了解containers概念，再到nodemanager资源配置，最后终于知道问题点就在控制containers个数，然后就开始研究到这几个配置项了，这几个配置项影响着每个计算节点上container的个数(Vcore也会影响，本文先不说，就先当vcore是充足的)，毕竟这段时间看日志报的都是OOM。

一、nodemanager/ratio

•  yarn.nodemanager.resource.memory-mb

集群中某个计算节点分配给nodemanager的最大可用内存，这个最大可用内存不是该节点最大内存，而是该节点最大内存划分出来的给nodemanager使用的内存，

该配置项在集群启动后，无法动态改变。

比如一个节点最大内存为128G，计划给nodemanager80%的内存资源，则设置yarn.nodemanager.resource.memory-mb为103G，其余25G用作该节点其他资源调配，保证这个计算节点正常运行。

这个配置默认是8G，集群并不会主动检测这个可用内存，如果节点内存资源少于8G，需要将这个配置项设置成实际的资源，如果不配置，集群会按照8G的资源调配，这样会导致可能同时创建过多的container而OOM。

我们这次的主要问题就是这里，因为开发环境是一台8G的电脑，没有配置这个参数，相当于整个节点内存全给创建container，明显是会出问题

•  yarn.nodemanager.vmem-pmem-ratio

虚拟内存的比例，默认是2.1，即每使用1G物理内存，分配2.1的虚拟内存。

该配置项在集群启动后，无法动态改变。

虚拟内存不够也会报oom，在nodemanager的日志中可以看到。

虚拟内存是个what ？？？

现在还不是很了解这个，只是有时会看到日志报虚拟内存OOM，推荐做法就是将这个值调大，

但至于多少合理，有待研究，毕竟不可能无上限

二、resourceManager

•  yarn.scheduler.minimum-allocation-mb

这个配置是用来指定单个容器(container)可申请的最小内存资源，

如果申请的内存资源小于这个配置项的值，则按最小值分配。（有的商业版禁止申请小于这个值的内存资源）

这个配置是会影响到单个节点上container个数的，所以比较重要。有下面的经验推荐值：

参考来自：https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.0.6.0/bk_installing_manually_book/content/rpm-chap1-11.html

注：但毕竟是推荐值，其实还是要根据实际情况，比如说这个推荐值的前提是计算节点就是计算节点，跑的其他进程少，可以这么干，像我们这次是单节点，整个集群所有服务都在一个节点上，即使是8G，也肯定不能用1024，512都有压力…

•  yarn.scheduler.maximum-allocation-mb

单个容器(container)可申请的最大内存资源，应用在运行时申请的内存不能超过这个配置项值，

因为这个配置项是指定一个container最大的内存，实际分配内存时并不是按照这个配置项分配，所以这个配置项可以配置成和nodemanager的可用内存(yarn.nodemanager.resource.memory-mb)一样即可，这样的话，意味着只要这个节点的nodemanager可用内存哪怕只够跑一个container，这个container也是可以启动的。

如果这个参数配置的比nodemanager的可用内存(yarn.nodemanager.resource.memory-mb)小，那么可能出现这个节点总内存即使足够提供所需内存的，但却无法启动container的情况。

三、map/reduce

•  mapreduce.map.memory.mb

指定map任务时申请的内存，是一个精确值，不是范围值，这就是一个map真实用到内存的值了。

这个配置是可以在脚本或代码中动态申请的，但是取值范围必须是在container内存大小值之间。

即 yarn.scheduler.minimum-allocation-mb < mapreduce.map.memory.mb < yarn.scheduler.maximum-allocation-mb

比如在hive中申请：set mapreduce.map.memory.mb=4096;

实际上，我们现在大部分脚本在执行前都是动态申请一下的。只要在container大小以内。

遗留问题：

这个值该如何配置。还是说不需要配置，只需要把控container的大小内存，有开发人员根据实际情况申请，

•  mapreduce.reduce.memory.mb

和map的是对应的，指定reduce任务执行时申请的内存，是一个精确值，不是范围值。

可以在脚本或者代码中动态申请，取值范围必须是在container内存大小值之间。

配置时建议这个值是map的2倍，这个可能是要考虑到多个map后数据可能会有一个reduce处理，根据实际需要来看。

•  mapreduce.map.java.opts

在map阶段的yarnchild进程执行jvm参数， 必须小于mapreduce.map.memory.mb

一般是 0.8 * mapreduce.map.memory.mb (默认0.8)

•  mapreduce.reduce.java.opts

在reduce阶段的yarnchild进程执行jvm参数， 必须小于mapreduce.reduce.memory.mb

一般是 0.8 * mapreduce.reduce.memory.mb (默认0.8)

四、applicationMaster

•  yarn.app.mapreduce.am.resource.mb

指定appMaster的运行内存，默认是1.5g。

appMaster也是运行在container中，所以如果修改了yarn.scheduler.maximum-allocation-mb，就要注意修改这个配置

这个值必须小于 yarn.scheduler.maximum-allocation-mb才可以启动appMaster