Yarn下MapReduce部分参数理解
部分原文来自 support.pivotal.io 的翻译，对于该篇文章中感觉概念模糊不清的地方我做了修正，并扩充了我自己的部分理解，有不正确基握猛的地方还望大家指正
Yarn Container就是一个yarn的java进程（这里容易被误解成类似Linux Container的概念），在Mapreduce中的AM，MapTask，ReduceTask， spark的driver和executor等等都作为Container在Yarn的框架上执行，你可以在RM的网页上看到Container的状态。
从上面的图可以看出map，reduce，AM container的JVM，“JVM”矩形代表服务进程，“Max heap”，“Max virtual”矩形代表NodeManager对JVM进程的最大内存和虚拟内存的限制。
以map container内存分配(“mapreduce.map.memory.mb“)设置为1536M为例，AM将会为container向RM请求2048mb的内存资源（原因见上）。这是一种逻辑上的分配，这个值被NodeManager用来监控改进程内存资源的使用搏桥率， 如果Task进程树（包括task启动子进程占用的内存，这样可以解决hadoop streaming任务内存跑飞的情况，实际上是对内存使用的一种软限制，至于为什么没有使用Cgroups做限制，大家可以自行查阅资料）的使用超过了2048MB ，NM将会把这个task给杀掉。
mapreduce.map.java.opts和mapreduce.map.memory.mb区别：JVM进程跑在container中， mapreduce.{map|reduce}.java.opts能够通过Xmx设置JVM最大的heap的使用，一般设置为0.75倍的 mapreduce.{map|reduce}.memory.mb ，因为需要为java code，非JVM内存使用等预留些空间，同理：spark executor在申请内存是也会为堆外内存预留一些空间，参数由 spark.yarn.executor.memoryOverhead 控制，算法为 max(384m, 0.07*spark.executor.memory) **
当一个皮袭mapreduce job完成时，你将会看到一系列的计数器被打印出来，下面的三个计数器展示了多少物理内存和虚拟内存被分配
默认的(“ yarn.nodemanager.vmem-pmem-ratio “)设置为2.1，意味则map container或者reduce container分配的虚拟内存超过2.1倍的(“ mapreduce.reduce.memory.mb “)或(“ mapreduce.map.memory.mb “)就会被NM给KILL掉，如果 (“ mapreduce.map.memory.mb ”) 被设置为1536M那么总的虚拟内存为2.1*1536=3225.6MB
当container的内存超出要求的，log将会打印一下信息
在 3.2 中，提到 yarn.scheduler.increment-allocation-mb 参数用于控制container内存增量，如果需要更细粒度控制container内存增量，则需要修改该参数，那么接写来分析一下这个参数如何工作的
先看下该参数在 FairSchedulerConfiguration.java 中的定义（顺带上cpu增量）
在 FairScheduler.java 中 initScheduler 方法中，初始化了一个 incrAllocation 对象，表明资源使用的增量
在具体 FairScheduler#allocate 方法中使用（allocate是每次资源分配过程中入口方法，在此不再赘述，有兴趣的同学自己可以下来看源码）
接下来，我们看下在 Sanity check 中发生了什么
看注释，实际上 normalizeRequests 方法对申请的资源进行了一个检查。
我们看到最终调用了 normalizeRequest 方法，再往下追，最终发现调用到 ResourceCalculator#normalize 方法，ResourceCalculator实例对象为 DominantResourceCalculator （参见allocate方法）
其中 stepFactor 对象为之前提到的 incrAllocation 对象，所以可以看出，在这里进行了一个计算资源请求的操作。
至此，这篇分析文章就要结束了，期间涉及到的一些细节并没有赘述，有兴趣的同学可以查阅源码做更深入的了解。
下篇文章，内容预告：
