Yarn下MapReduce部分参数理解

发布网友发布时间：2022-12-17 00:47

共1个回答

热心网友时间：2023-09-12 13:07

部分原文来自 support.pivotal.io 的翻译，对于该篇文章中感觉概念模糊不清的地方我做了修正，并扩充了我自己的部分理解，有不正确的地方还望大家指正

Yarn Container就是一个yarn的java进程（这里容易被误解成类似Linux Container的概念），在Maprece中的AM，MapTask，ReceTask， spark的driver和executor等等都作为Container在Yarn的框架上执行，你可以在RM的网页上看到Container的状态。

从上面的图可以看出map，rece，AM container的JVM，“JVM”矩形代表服务进程，“Max heap”，“Max virtual”矩形代表NodeManager对JVM进程的最大内存和虚拟内存的*。

以map container内存分配(“maprece.map.memory.mb“)设置为1536M为例，AM将会为container向RM请求2048mb的内存资源（原因见上）。这是一种逻辑上的分配，这个值被NodeManager用来监控改进程内存资源的使用率，如果Task进程树（包括task启动子进程占用的内存，这样可以解决hadoop streaming任务内存跑飞的情况，实际上是对内存使用的一种软*，至于为什么没有使用Cgroups做*，大家可以自行查阅资料）的使用超过了2048MB，NM将会把这个task给杀掉。

maprece.map.java.opts和maprece.map.memory.mb区别：JVM进程跑在container中， maprece.{map|rece}.java.opts能够通过Xmx设置JVM最大的heap的使用，一般设置为0.75倍的 maprece.{map|rece}.memory.mb ，因为需要为java code，非JVM内存使用等预留些空间，同理：spark executor在申请内存是也会为堆外内存预留一些空间，参数由 spark.yarn.executor.memoryOverhead 控制，算法为 max(384m, 0.07*spark.executor.memory) **

当一个maprece job完成时，你将会看到一系列的计数器被打印出来，下面的三个计数器展示了多少物理内存和虚拟内存被分配

默认的(“yarn.nodemanager.vmem-pmem-ratio“)设置为2.1，意味则map container或者rece container分配的虚拟内存超过2.1倍的(“maprece.rece.memory.mb“)或(“maprece.map.memory.mb“)就会被NM给KILL掉，如果 (“maprece.map.memory.mb”) 被设置为1536M那么总的虚拟内存为2.1*1536=3225.6MB

当container的内存超出要求的，log将会打印一下信息

在 3.2 中，提到 yarn.scheler.increment-allocation-mb参数用于控制container内存增量，如果需要更细粒度控制container内存增量，则需要修改该参数，那么接写来分析一下这个参数如何工作的

先看下该参数在FairSchelerConfiguration.java中的定义（顺带上cpu增量）

在FairScheler.java中 initScheler 方法中，初始化了一个incrAllocation对象，表明资源使用的增量

在具体FairScheler#allocate方法中使用（allocate是每次资源分配过程中入口方法，在此不再赘述，有兴趣的同学自己可以下来看源码）

接下来，我们看下在Sanity check中发生了什么

看注释，实际上normalizeRequests方法对申请的资源进行了一个检查。

我们看到最终调用了normalizeRequest方法，再往下追，最终发现调用到ResourceCalculator#normalize方法，ResourceCalculator实例对象为DominantResourceCalculator（参见allocate方法）

其中stepFactor对象为之前提到的incrAllocation对象，所以可以看出，在这里进行了一个计算资源请求的操作。

至此，这篇分析文章就要结束了，期间涉及到的一些细节并没有赘述，有兴趣的同学可以查阅源码做更深入的了解。

下篇文章，内容预告：