yarn 关于资源参数设置

最新推荐文章于 2024-08-19 04:01:37 发布

mllhxn

最新推荐文章于 2024-08-19 04:01:37 发布

阅读量2.4w

点赞数 3

分类专栏： hadoop 文章标签： hadoop

本文链接：https://blog.csdn.net/mlljava1111/article/details/51867883

版权

hadoop 专栏收录该内容

25 篇文章 0 订阅

订阅专栏

yarn-site.xml

yarn.scheduler.minimum-allocation-mb

yarn.scheduler.maximum-allocation-mb

说明：单个容器可申请的最小与最大内存，应用在运行申请内存时不能超过最大值，小于最小值则分配最小值，从这个角度看，最小值有点想操作系统中的页。最小值还有另外一种用途，计算一个节点的最大container数目注：这两个值一经设定不能动态改变(此处所说的动态改变是指应用运行时)。

默认值：1024/8192

yarn.scheduler.minimum-allocation-vcores

yarn.scheduler.maximum-allocation-vcores

参数解释：单个可申请的最小/最大虚拟CPU个数。比如设置为1和4，则运行MapRedce作业时，每个Task最少可申请1个虚拟CPU，最多可申请4个虚拟CPU。

默认值：1/32

yarn.nodemanager.resource.memory-mb

yarn.nodemanager.vmem-pmem-ratio

说明：每个节点可用的最大内存，RM中的两个值不应该超过此值。此数值可以用于计算container最大数目，即：用此值除以RM中的最小容器内存。虚拟内存率，是占task所用内存的百分比，默认值为2.1倍;注意：第一个参数是不可修改的，一旦设置，整个运行过程中不可动态修改，且该值的默认大小是8G，即使计算机内存不足8G也会按着8G内存来使用。

默认值：8G /2.1

yarn.nodemanager.resource.cpu-vcores

参数解释：NodeManager总的可用虚拟CPU个数。

默认值：8

AM内存配置相关参数，此处以MapReduce为例进行说明（这两个值是AM特性，应在mapred-site.xml中配置），如下：
mapreduce.map.memory.mb
mapreduce.reduce.memory.mb
说明：这两个参数指定用于MapReduce的两个任务（Map and Reduce task）的内存大小，其值应该在RM中的最大最小container之间。如果没有配置则通过如下简单公式获得：
max(MIN_CONTAINER_SIZE, (Total Available RAM) / containers))
一般的reduce应该是map的2倍。注：这两个值可以在应用启动时通过参数改变；

AM中其它与内存相关的参数，还有JVM相关的参数，这些参数可以通过，如下选项配置：
mapreduce.map.java.opts
mapreduce.reduce.java.opts
说明：这两个参主要是为需要运行JVM程序（java、scala等）准备的，通过这两个设置可以向JVM中传递参数的，与内存有关的是，-Xmx，-Xms等选项。此数值大小，应该在AM中的map.mb和reduce.mb之间。

我们对上面的内容进行下总结，当配置Yarn内存的时候主要是配置如下三个方面：每个Map和Reduce可用物理内存限制；对于每个任务的JVM对大小的限制；虚拟内存的限制；

下面通过一个具体错误实例，进行内存相关说明，错误如下：
Container[pid=41884,containerID=container_1405950053048_0016_01_000284] is running beyond virtual memory limits. Current usage: 314.6 MB of 2.9 GB physical memory used; 8.7 GB of 6.2 GB virtual memory used. Killing container.
配置如下：

<property>
    <name>yarn.nodemanager.resource.memory-mb</name>
    <value>100000</value>
</property>
<property>
    <name>yarn.scheduler.maximum-allocation-mb</name>
    <value>10000</value>
</property>
<property>
    <name>yarn.scheduler.minimum-allocation-mb</name>
    <value>3000</value>
</property>
<property>
    <name>mapreduce.reduce.memory.mb</name>
    <value>2000</value>
</property>

通过配置我们看到，容器的最小内存和最大内存分别为：3000m和10000m，而reduce设置的默认值小于2000m，map没有设置，所以两个值均为3000m，也就是log中的“2.9 GB physical memory used”。而由于使用了默认虚拟内存率(也就是2.1倍)，所以对于Map Task和Reduce Task总的虚拟内存为都为3000*2.1=6.2G。而应用的虚拟内存超过了这个数值，故报错。解决办法：在启动Yarn是调节虚拟内存率或者应用运行时调节内存大小.

mapred-site.xml

参数名称	缺省值	说明
mapreduce.job.name		作业名称
mapreduce.job.priority	NORMAL	作业优先级
yarn.app.mapreduce.am.resource.mb	1536	MR ApplicationMaster占用的内存量
yarn.app.mapreduce.am.resource.cpu-vcores	1	MR ApplicationMaster占用的虚拟CPU个数
mapreduce.am.max-attempts	2	MR ApplicationMaster最大失败尝试次数
mapreduce.map.memory.mb	1024	每个Map Task需要的内存量
mapreduce.map.cpu.vcores	1	每个Map Task需要的虚拟CPU个数
mapreduce.map.maxattempts	4	Map Task最大失败尝试次数
mapreduce.reduce.memory.mb	1024	每个Reduce Task需要的内存量
mapreduce.reduce.cpu.vcores	1	每个Reduce Task需要的虚拟CPU个数
mapreduce.reduce.maxattempts	4	Reduce Task最大失败尝试次数
mapreduce.map.speculative	false	是否对Map Task启用推测执行机制
mapreduce.reduce.speculative	false	是否对Reduce Task启用推测执行机制
mapreduce.job.queuename	default	作业提交到的队列
mapreduce.task.io.sort.mb	100	任务内部排序缓冲区大小
mapreduce.map.sort.spill.percent	0.8	Map阶段溢写文件的阈值（排序缓冲区大小的百分比）
mapreduce.reduce.shuffle.parallelcopies	5	Reduce Task启动的并发拷贝数据的线程数目

在上Yarn的框架管理中，无论是AM从RM申请资源，还是NM管理自己所在节点的资源，都是通过container进行的。Container是Yarn的资源抽象，此处的资源包括内存和cup等。下面对container，进行比较详细的介绍。为了是大家对container有个比较形象的认识，首先看下图：

从上图中我们可以看到，首先AM通过请求包ResourceRequest从RM申请资源，当获取到资源后，AM对其进行封装，封装成ContainerLaunchContext对象，通过这个对象，AM与NM进行通讯，以便启动该任务。下面通过ResourceRequest、container和ContainerLaunchContext的protocol
ResourceRequest结构如下：

message ResourceRequestProto {
optional PriorityProto priority = 1; // 资源优先级
optional string resource_name = 2; // 期望资源所在的host
optional ResourceProto capability = 3; // 资源量（mem、cpu）
optional int32 num_containers = 4; // 满足条件container个数
optional bool relax_locality = 5 ; //default = true; 
}

对上面结构进行简要按序号说明：
2：在提交申请时，期望从哪台主机上获得，但最终还是AM与RM协商决定；
3：只包含两种资源，即：内存和cpu，申请方式：
注：1、由于2与4并没有限制资源申请量，则AP在资源申请上是无限的。2、Yarn采用覆盖式资源申请方式，即：AM每次发出的资源请求会覆盖掉之前在同一节点且优先级相同的资源请求,也就是说同一节点中相同优先级的资源请求只能有一个。

container结构：

message ContainerProto {
optional ContainerIdProto id = 1; //container id
optional NodeIdProto nodeId = 2; //container（资源）所在节点
optional string node_http_address = 3;
optional ResourceProto resource = 4; //分配的container数量
optional PriorityProto priority = 5; //container的优先级
optional hadoop.common.TokenProto container_token = 6; //container token，用于安全认证
}

注：每个container一般可以运行一个任务，当AM收到多个container时，将进一步分给某个人物。如：MapReduce

ContainerLaunchContext结构：

message ContainerLaunchContextProto {
repeated StringLocalResourceMapProto localResources = 1; //该Container运行的程序所需的在资源，例如：jar包
optional bytes tokens = 2;//Security模式下的SecurityTokens
repeated StringBytesMapProto service_data = 3;
repeated StringStringMapProto environment = 4; //Container启动所需的环境变量
repeated string command = 5; //该Container所运行程序的命令,比如运行的为java程序,即$JAVA_HOME/bin/java org.ourclassrepeated ApplicationACLMapProto application_ACLs = 6;//该Container所属的Application的访问控制列表
}

下面结合一段代码，仅以ContainerLaunchContext为例进行描述(本应该写个简单的有限状态机的，便于大家理解，但时间不怎么充分)：

申请一个新的ContainerLaunchContext：

ContainerLaunchContext ctx = Records.newRecord(ContainerLaunchContext.class);
          填写必要的信息：
ctx.setEnvironment(...);
childRsrc.setResource(...);
ctx.setLocalResources(...);
ctx.setCommands(...);
启动任务：
startReq.setContainerLaunchContext(ctx);

最后对container进行如下总结：container是Yarn的资源抽象，封装了节点上的一些资源，主要是CPU与内存；container是AM向NM申请的，其运行是由AM向资源所在NM发起的，并最终运行
的。有两类container：一类是AM运行需要的container；另一类是AP为执行任务向RM申请的。

每个slave可以运行

map的数据<=yarn.nodemanager.resource.memory-mb/mapreduce.map.memory.mb,

reduce任务的数量<=yarn.nodemanager.resource.memory-mb/mapreduce.reduce.memory.mb