[YARN] Yarn下Mapreduce的内存参数理解

博客原文：

hackershell

这篇文章算是给本身从新缕清MR下内存参数的含义

Container是什么？

Container就是一个yarn的java进程，在Mapreduce中的AM，MapTask，ReduceTask都做为Container在Yarn的框架上执行，你能够在RM的网页上看到Container的状态

基础

Yarn的ResourceManger（简称RM）经过逻辑上的队列分配内存，CPU等资源给application，默认状况下RM容许最大AM申请Container资源为8192MB("yarn.scheduler.maximum-allocation-mb")，默认状况下的最小分配资源为1024M("yarn.scheduler.minimum-allocation-mb")，AM只能以增量（"yarn.scheduler.minimum-allocation-mb"）和不会超过("yarn.scheduler.maximum-allocation-mb")的值去向RM申请资源，AM负责将("mapreduce.map.memory.mb")和("mapreduce.reduce.memory.mb")的值规整到能被("yarn.scheduler.minimum-allocation-mb")整除，RM会拒绝申请内存超过8192MB和不能被1024MB整除的资源请求。

相关参数

YARN

• yarn.scheduler.minimum-allocation-mb

• yarn.scheduler.maximum-allocation-mb

• yarn.nodemanager.vmem-pmem-ratio

• yarn.nodemanager.resource.memory.mb

MapReduce

Map Memory

• mapreduce.map.java.opts

• mapreduce.map.memory.mb

Reduce Memory

• mapreduce.reduce.java.opts

• mapreduce.reduce.memory.mb

从上面的图能够看出map，reduce，AM container的JVM，“JVM”矩形表明服务进程，“Max heap”，“Max virtual”矩形表明NodeManager对JVM进程的最大内存和虚拟内存的限制。

以map container内存分配("mapreduce.map.memory.mb")设置为1536为例，AM将会为container向RM请求2048mb的内存资源，由于最小分配单位("yarn.scheduler.minimum-allocation-mb")被设置为1024，这是一种逻辑上的分配，这个值被NodeManager用来监控改进程内存资源的使用率，若是map Task堆的使用率超过了2048MB，NM将会把这个task给杀掉，JVM进程堆的大小被设置为1024("mapreduce.map.java.opts=-Xmx1024m")适合在逻辑分配为2048MB中，一样reduce container("mapreduce.reduce.memory.mb")设置为3072也是.

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

Physical memory (bytes) snapshot=21850116096
Virtual memory (bytes) snapshot=40047247360
Total committed heap usage (bytes)=22630105088

虚拟内存

默认的("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") 被设置为1536那么总的虚拟内存为2.1*1536=3225.6MB

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

Current usage: 2.1gb of 2.0gb physical memory used; 1.6gb of 3.15gb virtual memory used. Killing container.

mapreduce.map.java.opts和mapreduce.map.memory.mb

大概了解完以上的参数以后，mapreduce.map.java.opts和mapreduce.map.memory.mb参数之间，有什么联系呢？

经过上面的分析，咱们知道若是一个yarn的container超除了heap设置的大小，这个task将会失败，咱们能够根据哪一种类型的container失败去相应增大mapreduce.{map|reduce}.memory.mb去解决问题。 但同时带来的问题是集群并行跑的container的数量少了，因此适当的调整内存参数对集群的利用率的提高尤其重要。

由于在yarn container这种模式下，JVM进程跑在container中，mapreduce.{map|reduce}.java.opts可以经过Xmx设置JVM最大的heap的使用，通常设置为0.75倍的memory.mb，由于须要为java code，非JVM内存使用等预留些空间

补充一下

对于FairScheduler来讲（其余我也没看），存在着一个增量参数

/** Increment request grant-able by the RM scheduler.

• These properties are looked up in the yarn-site.xml */
  public static final String RM_SCHEDULER_INCREMENT_ALLOCATION_MB =
  YarnConfiguration.YARN_PREFIX + "scheduler.increment-allocation-mb";
  public static final int DEFAULT_RM_SCHEDULER_INCREMENT_ALLOCATION_MB = 1024;

对于线上2560MB最小分配内存，客户端的内存为2048，incrementMemory为1024，经过其计算算法得出值，demo以下

/**

• Created by shangwen on 15-9-14.
  */

  public class TestCeil {

  public static void main(String[] args) {

  int clientMemoryReq = 2048;
     int minAllowMermory = 2560;
     int incrementResource = 1024;
     System.out.println(roundUp(Math.max(clientMemoryReq,minAllowMermory),incrementResource));
     // output 3072

  }

  public static int divideAndCeil(int a, int b) {

  if (b == 0) {
         return 0;
     }
     return (a + (b - 1)) / b;

  }

  public static int roundUp(int a, int b) {

  System.out.println("divideAndCeil:" + divideAndCeil(a, b));
     return divideAndCeil(a, b) * b;

  }

  }

得出的结果为3072MB，即对于map来讲，则会分配3G内存，即便你在客户端写的是2G，因此你能够看到如下日志：

Container [pid=35691,containerID=container_1441194300243_383809_01_000181] is running beyond physical memory limits. Current usage: 3.0 GB of 3 GB physical memory used; 5.4 GB of 9.3 GB virtual memory used.

对于56G内存的NM来讲，若是所有跑map则56/3大约跑18个container

假设修改最小分配为默认的1024，则分配的内存为2G，即大约能够跑56/2约28个container。

经过上述的描述，大概就对其参数有个比较综合的了解了。

参考资料

Mapreduce YARN Memory Parameters