YARN内存使用优化配置

在Hadoop2.0中, YARN负责管理MapReduce中的资源(内存, CPU等)并且将其打包成Container. 这样可以精简MapReduce, 使之专注于其擅长的数据处理任务, 将无需考虑资源调度. 如下图所示 
YARN会管理集群中所有机器的可用计算资源. 基于这些资源YARN会调度应用(比如MapReduce)发来的资源请求, 然后YARN会通过分配Container来给每个应用提供处理能力, Container是YARN中处理能力的基本单元, 是对内存, CPU等的封装.

目前我这里的服务器情况：6台slave，每台：32G内存，2*6核CPU。

由于hadoop 1.x存在JobTracker和TaskTracker，资源管理有它们实现，在执行mapreduce作业时，资源分为map task和reduce task。所有存在下面两个参数分别设置每个TaskTracker可以运行的任务数：

<property>
  <name>mapred.tasktracker.map.tasks.maximum</name>
  <value>6</value>
  <description><![CDATA[CPU数量=服务器CPU总核数 / 每个CPU的核数；服务器CPU总核数 = more /proc/cpuinfo | grep 'processor' | wc -l；每个CPU的核数 = more /proc/cpui nfo | grep 'cpu cores']]></description>
</property>
<property>
    <name>mapred.tasktracker.reduce.tasks.maximum</name>
    <value>4</value>
    <description>一个task tracker最多可以同时运行的reduce任务数量</description>
</property>

但是在hadoop 2.x中，引入了Yarn架构做资源管理，在每个节点上面运行NodeManager负责节点资源的分配，而slot也不再像1.x那样区分Map slot和Reduce slot。在Yarn上面Container是资源的分配的最小单元。

Yarn集群的内存分配配置在yarn-site.xml文件中配置：

<property>
    <name>yarn.nodemanager.resource.memory-mb</name>
    <value>22528</value>
    <discription>每个节点可用内存,单位MB</discription>
  </property>
  
  <property>
    <name>yarn.scheduler.minimum-allocation-mb</name>
    <value>1500</value>
    <discription>单个任务可申请最少内存，默认1024MB</discription>
  </property>
  
  <property>
    <name>yarn.scheduler.maximum-allocation-mb</name>
    <value>16384</value>
    <discription>单个任务可申请最大内存，默认8192MB</discription>
  </property>

 由于我Yarn集群还需要跑Spark的任务，而Spark的Worker内存相对需要大些，所以需要调大单个任务的最大内存（默认为8G）。

而Mapreduce的任务的内存配置：

<property>
    <name>mapreduce.map.memory.mb</name>
    <value>1500</value>
    <description>每个Map任务的物理内存限制</description>
  </property>
  
  <property>
    <name>mapreduce.reduce.memory.mb</name>
    <value>3000</value>
    <description>每个Reduce任务的物理内存限制</description>
  </property>
  
  <property>
    <name>mapreduce.map.java.opts</name>
    <value>-Xmx1200m</value>
  </property>
  
  <property>
    <name>mapreduce.reduce.java.opts</name>
    <value>-Xmx2600m</value>
  </property>

mapreduce.map.memory.mb：每个map任务的内存，应该是大于或者等于Container的最小内存。

按照上面的配置：每个slave可以运行map的数据<= 22528/1500,reduce任务的数量<=22528/3000

Hadoop  YARN同时支持内存和CPU两种资源的调度（默认只支持内存，如果想进一步调度CPU，需要自己进行一些配置），本文将介绍YARN是如何对这些资源进行调度和隔离的。
在YARN中，资源管理由ResourceManager和NodeManager共同完成，其中，ResourceManager中的调度器负责资源的分配，而NodeManager则负责资源的供给和隔离。ResourceManager将某个NodeManager上资源分配给任务（这就是所谓的“资源调度”）后，NodeManager需按照要求为任务提供相应的资源，甚至保证这些资源应具有独占性，为任务运行提供基础的保证，这就是所谓的资源隔离。
关于Hadoop YARN资源调度器的详细介绍，可参考我的这篇文章：YARN/MRv2 Resource Manager深入剖析—资源调度器。
在正式介绍具体的资源调度和隔离之前，先品味一下内存和CPU这两种资源的特点，这是两种性质不同的资源。内存资源的多少会会决定任务的生死，如果内存不够，任务可能会运行失败；相比之下，CPU资源则不同，它只会决定任务运行的快慢，不会对生死产生影响。
【YARN中内存资源的调度和隔离】
基于以上考虑，YARN允许用户配置每个节点上可用的物理内存资源，注意，这里是“可用的”，因为一个节点上的内存会被若干个服务共享，比如一部分给YARN，一部分给HDFS，一部分给HBase等，YARN配置的只是自己可以使用的，配置参数如下：
（1）yarn.nodemanager.resource.memory-mb
表示该节点上YARN可使用的物理内存总量，默认是8192（MB），注意，如果你的节点内存资源不够8GB，则需要调减小这个值，而YARN不会智能的探测节点的物理内存总量。
（2）yarn.nodemanager.vmem-pmem-ratio
任务每使用1MB物理内存，最多可使用虚拟内存量，默认是2.1。
（3） yarn.nodemanager.pmem-check-enabled
是否启动一个线程检查每个任务正使用的物理内存量，如果任务超出分配值，则直接将其杀掉，默认是true。
（4） yarn.nodemanager.vmem-check-enabled
是否启动一个线程检查每个任务正使用的虚拟内存量，如果任务超出分配值，则直接将其杀掉，默认是true。
（5）yarn.scheduler.minimum-allocation-mb
单个任务可申请的最少物理内存量，默认是1024（MB），如果一个任务申请的物理内存量少于该值，则该对应的值改为这个数。
（6）yarn.scheduler.maximum-allocation-mb
单个任务可申请的最多物理内存量，默认是8192（MB）。
默认情况下，YARN采用了线程监控的方法判断任务是否超量使用内存，一旦发现超量，则直接将其杀死。由于Cgroups对内存的控制缺乏灵活性（即任务任何时刻不能超过内存上限，如果超过，则直接将其杀死或者报OOM），而Java进程在创建瞬间内存将翻倍，之后骤降到正常值，这种情况下，采用线程监控的方式更加灵活（当发现进程树内存瞬间翻倍超过设定值时，可认为是正常现象，不会将任务杀死），因此YARN未提供Cgroups内存隔离机制。
【YARN中CPU资源的调度和隔离】
在YARN中，CPU资源的组织方式仍在探索中，目前（2.2.0版本）只是一个初步的，非常粗粒度的实现方式，更细粒度的CPU划分方式已经提出来了，正在完善和实现中。
目前的CPU被划分成虚拟CPU（CPU virtual Core），这里的虚拟CPU是YARN自己引入的概念，初衷是，考虑到不同节点的CPU性能可能不同，每个CPU具有的计算能力也是不一样的，比如某个物理CPU的计算能力可能是另外一个物理CPU的2倍，这时候，你可以通过为第一个物理CPU多配置几个虚拟CPU弥补这种差异。用户提交作业时，可以指定每个任务需要的虚拟CPU个数。在YARN中，CPU相关配置参数如下：
（1）yarn.nodemanager.resource.cpu-vcores
表示该节点上YARN可使用的虚拟CPU个数，默认是8，注意，目前推荐将该值设值为与物理CPU核数数目相同。如果你的节点CPU核数不够8个，则需要调减小这个值，而YARN不会智能的探测节点的物理CPU总数。
（2） yarn.scheduler.minimum-allocation-vcores
单个任务可申请的最小虚拟CPU个数，默认是1，如果一个任务申请的CPU个数少于该数，则该对应的值改为这个数。
（3）yarn.scheduler.maximum-allocation-vcores
单个任务可申请的最多虚拟CPU个数，默认是32。
默认情况下，YARN是不会对CPU资源进行调度的，你需要配置相应的资源调度器让你支持，具体可参考我的这两篇文章：
（1）Hadoop YARN配置参数剖析（4）—Fair Scheduler相关参数
（2）Hadoop YARN配置参数剖析（5）—Capacity Scheduler相关参数
默认情况下，NodeManager不会对CPU资源进行任何隔离，你可以通过启用Cgroups让你支持CPU隔离。
由于CPU资源的独特性，目前这种CPU分配方式仍然是粗粒度的。举个例子，很多任务可能是IO密集型的，消耗的CPU资源非常少，如果此时你为它分配一个CPU，则是一种严重浪费，你完全可以让他与其他几个任务公用一个CPU，也就是说，我们需要支持更粒度的CPU表达方式。
借鉴亚马逊EC2中CPU资源的划分方式，即提出了CPU最小单位为EC2 Compute Unit（ECU），一个ECU代表相当于1.0-1.2 GHz 2007 Opteron or 2007 Xeon处理器的处理能力。YARN提出了CPU最小单位YARN Compute Unit（YCU），目前这个数是一个整数，默认是720，由参数yarn.nodemanager.resource.cpu-ycus-per-core设置，表示一个CPU core具备的计算能力（该feature在2.2.0版本中并不存在，可能增加到2.3.0版本中），这样，用户提交作业时，直接指定需要的YCU即可，比如指定值为360，表示用1/2个CPU core，实际表现为，只使用一个CPU core的1/2计算时间。注意，在操作系统层，CPU资源是按照时间片分配的，你可以说，一个进程使用1/3的CPU时间片，或者1/5的时间片。对于CPU资源划分和调度的探讨，可参考以下几个链接：
https://issues.apache.org/jira/browse/YARN-1089
https://issues.apache.org/jira/browse/YARN-1024
Hadoop 新特性、改进、优化和Bug分析系列5：YARN-3
【总结】
目前，YARN 内存资源调度借鉴了Hadoop 1.0中的方式，比较合理，但CPU资源的调度方式仍在不断改进中，目前只是一个初步的粗糙实现，相信在不久的将来，YARN 中CPU资源的调度将更加完善。