版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/kyle0349/article/details/82084980
最近项目在用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个数的，所以比较重要。有下面的经验推荐值：
| Total RAM per Node | Recommended Minimum Container Size |
|---|---|
| Less than 4 GB | 256 MB |
| Between 4 GB and 8 GB | 512 MB |
| Between 8 GB and 24 GB | 1024 MB |
| Above 24 GB | 2048 MB |
参考来自：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
mapreduce.reduce.java.opts
- 在reduce阶段的yarnchild进程执行jvm参数， 必须小于mapreduce.reduce.memory.mb
- 一般是 0.8 * mapreduce.reduce.memory.mb
四、applicationMaster
yarn.app.mapreduce.am.resource.mb
- 指定appMaster的运行内存，默认是1.5g。
- appMaster也是运行在container中，所以如果修改了yarn.scheduler.maximum-allocation-mb，就要注意修改这个配置
- 这个值必须小于 yarn.scheduler.maximum-allocation-mb才可以启动appMaster
以上是个人见解，大数据是个超级万花筒，有不同看法，一起探讨，能解决问题是最好的…