Hadoop YARN同时支持内存和CPU两种资源的调度,本文介绍如何配置YARN对内存和CPU的使用。
YARN作为一个资源调度器,应该考虑到集群里面每一台机子的计算资源,然后根据application申请的资源进行分配Container。Container是YARN里面资源分配的基本单位,具有一定的内存以及CPU资源。
在YARN集群中,平衡内存、CPU、磁盘的资源的很重要的,根据经验,每两个container使用一块磁盘以及一个CPU核的时候可以使集群的资源得到一个比较好的利用。
内存配置
关于内存相关的配置可以参考hortonwork公司的文档Determine HDP Memory Configuration Settings来配置你的集群。
YARN以及MAPREDUCE所有可用的内存资源应该要除去系统运行需要的以及其他的hadoop的一些程序,总共保留的内存=系统内存+HBASE内存。
可以参考下面的表格确定应该保留的内存:
每台机子内存 | 系统需要的内存 | HBase需要的内存 |
---|---|---|
4GB | 1GB | 1GB |
8GB | 2GB | 1GB |
16GB | 2GB | 2GB |
24GB | 4GB | 4GB |
48GB | 6GB | 8GB |
64GB | 8GB | 8GB |
72GB | 8GB | 8GB |
96GB | 12GB | 16GB |
128GB | 24GB | 24GB |
255GB | 32GB | 32GB |
512GB | 64GB | 64GB |
计算每台机子最多可以拥有多少个container,可以使用下面的公式:
containers = min (2*CORES, 1.8*DISKS, (Total available RAM) / MIN_CONTAINER_SIZE)
说明:
- CORES为机器CPU核数
- DISKS为机器上挂载的磁盘个数
- Total available RAM为机器总内存
- MIN_CONTAINER_SIZE是指container最小的容量大小,这需要根据具体情况去设置,可以参考下面的表格:
每台机子可用的RAM | container最小值 |
---|---|
小于4GB | 256MB |
4GB到8GB之间 | 512MB |
8GB到24GB之间 | 1024MB |
大于24GB | 2048MB |
每个container的平均使用内存大小计算方式为:
RAM-per-container = max(MIN_CONTAINER_SIZE, (Total Available RAM) / containers))
通过上面的计算,YARN以及MAPREDUCE可以这样配置:
配置文件 | 配置设置 | 默认值 | 计算值 |
---|---|---|---|
yarn-site.xml | yarn.nodemanager.resource.memory-mb | 8192 MB | = containers * RAM-per-container |
yarn-site.xml | yarn.scheduler.minimum-allocation-mb | 1024MB | = RAM-per-container |
yarn-site.xml | yarn.scheduler.maximum-allocation-mb | 8192 MB | = containers * RAM-per-container |
yarn-site.xml (check) | yarn.app.mapreduce.am.resource.mb | 1536 MB | = 2 * RAM-per-container |
yarn-site.xml (check) | yarn.app.mapreduce.am.command-opts | -Xmx1024m | = 0.8 * 2 * RAM-per-container |
mapred-site.xml | mapreduce.map.memory.mb | 1024 MB | = RAM-per-container |
mapred-site.xml | mapreduce.reduce.memory.mb | 1024 MB | = 2 * RAM-per-container |
mapred-site.xml | mapreduce.map.java.opts | = 0.8 * RAM-per-container | |
mapred-site.xml | mapreduce.reduce.java.opts | = 0.8 * 2 * RAM-per-container |
举个例子:对于128G内存、32核CPU的机器,挂载了7个磁盘,根据上面的说明,系统保留内存为24G,不适应HBase情况下,系统剩余可用内存为104G,计算containers值如下:
containers = min (2*32, 1.8* 7 , (128-24)/2) = min (64, 12.6 , 51) = 13
计算RAM-per-container值如下:
RAM-per-container = max (2, (124-24)/13) = max (2, 8) = 8
你也可以使用脚本yarn-utils.py来计算上面的值:
点击(此处)折叠或打开
- #!/usr/bin/env python
- import optparse
- from pprint import pprint
- import logging
- import sys
- import math
- import ast
- ''' Reserved for OS + DN + NM, Map: Memory => Reservation '''
- reservedStack = { 4:1, 8:2, 16:2, 24:4, 48:6, 64:8, 72:8, 96:12,
- 128:24, 256:32, 512:64}
- ''' Reserved for HBase. Map: Memory => Reservation '''
- reservedHBase = {4:1, 8:1, 16:2, 24:4, 48:8, 64:8, 72:8, 96:16,
- 128:24, 256:32, 512:64}
- GB = 1024
- def getMinContainerSize(memory):
- if (memory <= 4):
- return 256
- elif (memory <= 8):
- return 512
- elif (memory <= 24):
- return 1024
- else:
- return 2048
- pass
- def getReservedStackMemory(memory):
- if (reservedStack.has_key(memory)):
- return reservedStack[memory]
- if (memory <= 4):
- ret = 1
- elif (memory >= 512):
- ret = 64
- else:
- ret = 1
- return ret
- def getReservedHBaseMem(memory):
- if (reservedHBase.has_key(memory)):
- return reservedHBase[memory]
- if (memory <= 4):
- ret = 1
- elif (memory >= 512):
- ret = 64
- else:
- ret = 2
- return ret
- def main():
- log = logging.getLogger(__name__)
- out_hdlr = logging.StreamHandler(sys.stdout)
- out_hdlr.setFormatter(logging.Formatter(' %(message)s'))
- out_hdlr.setLevel(logging.INFO)
- log.addHandler(out_hdlr)
- log.setLevel(logging.INFO)
- parser = optparse.OptionParser()
- memory = 0
- cores = 0
- disks = 0
- hbaseEnabled = True
- parser.add_option('-c', '--cores', default = 16,
- help = 'Number of cores on each host')
- parser.add_option('-m', '--memory', default = 64,
- help = 'Amount of Memory on each host in GB')
- parser.add_option('-d', '--disks', default = 4,
- help = 'Number of disks on each host')
- parser.add_option('-k', '--hbase', default = "True",
- help = 'True if HBase is installed, False is not')
- (options, args) = parser.parse_args()
- cores = int (options.cores)
- memory = int (options.memory)
- disks = int (options.disks)
- hbaseEnabled = ast.literal_eval(options.hbase)
- log.info("Using cores=" + str(cores) + " memory=" + str(memory) + "GB" +
- " disks=" + str(disks) + " hbase=" + str(hbaseEnabled))
- minContainerSize = getMinContainerSize(memory)
- reservedStackMemory = getReservedStackMemory(memory)
- reservedHBaseMemory = 0
- if (hbaseEnabled):
- reservedHBaseMemory = getReservedHBaseMem(memory)
- reservedMem = reservedStackMemory + reservedHBaseMemory
- usableMem = memory - reservedMem
- memory -= (reservedMem)
- if (memory < 2):
- memory = 2
- reservedMem = max(0, memory - reservedMem)
- memory *= GB
- containers = int (min(2 * cores,
- min(math.ceil(1.8 * float(disks)),
- memory/minContainerSize)))
- if (containers <= 2):
- containers = 3
- log.info("Profile: cores=" + str(cores) + " memory=" + str(memory) + "MB"
- + " reserved=" + str(reservedMem) + "GB" + " usableMem="
- + str(usableMem) + "GB" + " disks=" + str(disks))
- container_ram = abs(memory/containers)
- if (container_ram > GB):
- container_ram = int(math.floor(container_ram / 512)) * 512
- log.info("Num Container=" + str(containers))
- log.info("Container Ram=" + str(container_ram) + "MB")
- log.info("Used Ram=" + str(int (containers*container_ram/float(GB))) + "GB")
- log.info("Unused Ram=" + str(reservedMem) + "GB")
- log.info("yarn.scheduler.minimum-allocation-mb=" + str(container_ram))
- log.info("yarn.scheduler.maximum-allocation-mb=" + str(containers*container_ram))
- log.info("yarn.nodemanager.resource.memory-mb=" + str(containers*container_ram))
- map_memory = container_ram
- reduce_memory = 2*container_ram if (container_ram <= 2048) else container_ram
- am_memory = max(map_memory, reduce_memory)
- log.info("mapreduce.map.memory.mb=" + str(map_memory))
- log.info("mapreduce.map.java.opts=-Xmx" + str(int(0.8 * map_memory)) +"m")
- log.info("mapreduce.reduce.memory.mb=" + str(reduce_memory))
- log.info("mapreduce.reduce.java.opts=-Xmx" + str(int(0.8 * reduce_memory)) + "m")
- log.info("yarn.app.mapreduce.am.resource.mb=" + str(am_memory))
- log.info("yarn.app.mapreduce.am.command-opts=-Xmx" + str(int(0.8*am_memory)) + "m")
- log.info("mapreduce.task.io.sort.mb=" + str(int(0.4 * map_memory)))
- pass
- if __name__ == '__main__':
- try:
- main()
- except(KeyboardInterrupt, EOFError):
- print("\nAborting ... Keyboard Interrupt.")
- sys.exit(1)
执行下面命令:
python yarn-utils.py -c 32 -m 128 -d 7 -k False
返回结果如下:
点击(此处)折叠或打开
- Using cores=32 memory=128GB disks=7 hbase=False
- Profile: cores=32 memory=106496MB reserved=24GB usableMem=104GB disks=7
- Num Container=13
- Container Ram=8192MB
- Used Ram=104GB
- Unused Ram=24GB
- yarn.scheduler.minimum-allocation-mb=8192
- yarn.scheduler.maximum-allocation-mb=106496
- yarn.nodemanager.resource.memory-mb=106496
- mapreduce.map.memory.mb=8192
- mapreduce.map.java.opts=-Xmx6553m
- mapreduce.reduce.memory.mb=8192
- mapreduce.reduce.java.opts=-Xmx6553m
- yarn.app.mapreduce.am.resource.mb=8192
- yarn.app.mapreduce.am.command-opts=-Xmx6553m
- mapreduce.task.io.sort.mb=3276
这样的话,每个container内存为8G,似乎有点多,我更愿意根据集群使用情况任务将其调整为2G内存,则集群中下面的参数配置值如下:
配置文件 | 配置设置 | 计算值 |
---|---|---|
yarn-site.xml | yarn.nodemanager.resource.memory-mb | = 52 * 2 =104 G |
yarn-site.xml | yarn.scheduler.minimum-allocation-mb | = 2G |
yarn-site.xml | yarn.scheduler.maximum-allocation-mb | = 52 * 2 = 104G |
yarn-site.xml (check) | yarn.app.mapreduce.am.resource.mb | = 2 * 2=4G |
yarn-site.xml (check) | yarn.app.mapreduce.am.command-opts | = 0.8 * 2 * 2=3.2G |
mapred-site.xml | mapreduce.map.memory.mb | = 2G |
mapred-site.xml | mapreduce.reduce.memory.mb | = 2 * 2=4G |
mapred-site.xml | mapreduce.map.java.opts | = 0.8 * 2=1.6G |
mapred-site.xml | mapreduce.reduce.java.opts | = 0.8 * 2 * 2=3.2G |
对应的xml配置为:
点击(此处)折叠或打开
- <property>
- <name>yarn.nodemanager.resource.memory-mb</name>
- <value>106496</value>
- </property>
- <property>
- <name>yarn.scheduler.minimum-allocation-mb</name>
- <value>2048</value>
- </property>
- <property>
- <name>yarn.scheduler.maximum-allocation-mb</name>
- <value>106496</value>
- </property>
- <property>
- <name>yarn.app.mapreduce.am.resource.mb</name>
- <value>4096</value>
- </property>
- <property>
- <name>yarn.app.mapreduce.am.command-opts</name>
- <value>-Xmx3276m</value>
- </property>
另外,还有一下几个参数:
- yarn.nodemanager.vmem-pmem-ratio:任务每使用1MB物理内存,最多可使用虚拟内存量,默认是2.1。
- yarn.nodemanager.pmem-check-enabled:是否启动一个线程检查每个任务正使用的物理内存量,如果任务超出分配值,则直接将其杀掉,默认是true。
- yarn.nodemanager.vmem-pmem-ratio:是否启动一个线程检查每个任务正使用的虚拟内存量,如果任务超出分配值,则直接将其杀掉,默认是true。
第一个参数的意思是当一个map任务总共分配的物理内存为2G的时候,该任务的container最多内分配的堆内存为1.6G,可以分配的虚拟内存上限为2*2.1=4.2G。另外,照这样算下去,每个节点上YARN可以启动的Map数为104/2=52个。
CPU配置
YARN中目前的CPU被划分成虚拟CPU(CPU virtual Core),这里的虚拟CPU是YARN自己引入的概念,初衷是,考虑到不同节点的CPU性能可能不同,每个CPU具有的计算能力也是不一样的,比如某个物理CPU的计算能力可能是另外一个物理CPU的2倍,这时候,你可以通过为第一个物理CPU多配置几个虚拟CPU弥补这种差异。用户提交作业时,可以指定每个任务需要的虚拟CPU个数。
在YARN中,CPU相关配置参数如下:
- yarn.nodemanager.resource.cpu-vcores:表示该节点上YARN可使用的虚拟CPU个数,默认是8,注意,目前推荐将该值设值为与物理CPU核数数目相同。如果你的节点CPU核数不够8个,则需要调减小这个值,而YARN不会智能的探测节点的物理CPU总数。
- yarn.scheduler.minimum-allocation-vcores:单个任务可申请的最小虚拟CPU个数,默认是1,如果一个任务申请的CPU个数少于该数,则该对应的值改为这个数。
- yarn.scheduler.maximum-allocation-vcores:单个任务可申请的最多虚拟CPU个数,默认是32。
对于一个CPU核数较多的集群来说,上面的默认配置显然是不合适的,在我的测试集群中,4个节点每个机器CPU核数为31,留一个给操作系统,可以配置为:
点击(此处)折叠或打开
- <property>
- <name>yarn.nodemanager.resource.cpu-vcores</name>
- <value>31</value>
- </property>
- <property>
- <name>yarn.scheduler.maximum-allocation-vcores</name>
- <value>124</value>
- </property>
把CDH搭建起来了,跑其中的例子程序word-count。在控制台界面一直显示map 0% reduce 0% , 通过web页面查看job的状态一直是run,但是map没有执行。感觉是是资源的分配有问题。接着查看了任务的日志。
2014-07-04 17:30:37,492 INFO [RMCommunicator Allocator] org.apache.hadoop.mapreduce.v2.app.rm.RMContainerAllocator: Recalculating schedule, headroom=0 2014-07-04 17:30:37,492 INFO [RMCommunicator Allocator] org.apache.hadoop.mapreduce.v2.app.rm.RMContainerAllocator: Reduce slow start threshold not met. completedMapsForReduceSlowstart 2 2014-07-04 17:30:38,496 INFO [RMCommunicator Allocator] org.apache.hadoop.mapreduce.v2.app.rm.RMContainerAllocator: Ramping down all scheduled reduces:0 2014-07-04 17:30:38,496 INFO [RMCommunicator Allocator] org.apache.hadoop.mapreduce.v2.app.rm.RMContainerAllocator: Going to preempt 0
日志中没有任何的错误,但是一直打印该信息,应该是RM资源分配不够。
YARN中,资源包括内存和CPU,资源的管理是由ResourceManager和NodeManager共同完成,ResourceManager负责所有节点资源的管理和调度。NodeManager负责进程所在结点资源的分配和隔离。ResourceManager将某个NodeManager上资源分配给任务。下面详细介绍其中的一些重要参数。
yarn.nodemanager.resource.memory-mb
每个节点可用的内存, 它的单 位是mb,默认是8G,用于供NodeManager分配的。我出现的问题是资源分配太小,只有1G。
yarn.scheduler.minimum-allocation-mb
单个任务可申请的最小内存,默认是1024mb,稍微大一点,避免小的资源浪费情况,我本机资源少,所以给他分配了512mb, 失败的原因也就是这个分配过大。
yarn.scheduler.maximum-allocation-mb
单个任务可申请的最大内存,默认是8192mb. 如果是spark任务的话,这里调大吧
mapreduce.map.memory.mb
每个map任务的物理内存限制,应该大于或等于yarn.scheduler.minimum-allocation-mb
mapreduce.reduce.memory.mb
每个reduce任务的物理内存限制
mapreduce.map.java.opts
每个map进程的jvm堆的大小
mapreduce.reduce.java.opts
每个reduce进程的jvm堆的大小
每个节点可以运行map数和redue输,由yarn.nodemanager.resource.memory-mb除于mapreduce.map.memory.mb和mapreduce.reduce.memory.mb得到
yarn资源memory与core计算配置
yarn调度分配主要是针对Memory与CPU进行管理分配,并将其组合抽象成container来管理计算使用
memory配置
计算每台机子最多可以拥有多少个container:
containers = min (2*CORES, 1.8*DISKS, (Total available RAM) / MIN_CONTAINER_SIZE)
说明:
CORES为机器CPU核数
DISKS为机器上挂载的磁盘个数
Total available RAM为机器总内存
MIN_CONTAINER_SIZE是指container最小的容量大小,这需要根据具体情况去设置,可以参考下面的表格:
每个container的平均使用内存大小计算方式为:
RAM-per-container = max(MIN_CONTAINER_SIZE, (Total Available RAM) / containers))
相关配置调整说明:
(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 单个container可申请的最少物理内存量,默认是1024(MB),如果一个任务申请的物理内存量少于该值,则该对应的值改为这个数。 (6)yarn.scheduler.maximum-allocation-mb 单个container可申请的最多物理内存量,默认是8192(MB)。
默认情况下,YARN采用了线程监控的方法判断任务是否超量使用内存,一旦发现超量,则直接将其杀死。由于Cgroups对内存的控制缺乏灵活性(即任务任何时刻不能超过内存上限,如果超过,则直接将其杀死或者报OOM),而Java进程在创建瞬间内存将翻倍,之后骤降到正常值,这种情况下,采用线程监控的方式更加灵活(当发现进程树内存瞬间翻倍超过设定值时,可认为是正常现象,不会将任务杀死),因此YARN未提供Cgroups内存隔离机制。
CPU配置
在yarn中使用的是虚拟CPU,这里的虚拟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
本文汇总了几个hadoop yarn中常见问题以及解决方案,注意,本文介绍解决方案适用于hadoop 2.2.0以及以上版本。
(1) 默认情况下,各个节点的负载不均衡(任务数目不同),有的节点很多任务在跑,有的没有任务,怎样让各个节点任务数目尽可能均衡呢?
答: 默认情况下,资源调度器处于批调度模式下,即一个心跳会尽可能多的分配任务,这样,优先发送心跳过来的节点将会把任务领光(前提:任务数目远小于集群可以同时运行的任务数量),为了避免该情况发生,可以按照以下说明配置参数:
如果采用的是fair scheduler,可在yarn-site.xml中,将参数yarn.scheduler.fair.max.assign设置为1(默认是-1,)
如果采用的是capacity scheduler(默认调度器),则不能配置,目前该调度器不带负载均衡之类的功能。
当然,从hadoop集群利用率角度看,该问题不算问题,因为一般情况下,用户任务数目要远远大于集群的并发处理能力的,也就是说,通常情况下,集群时刻处于忙碌状态,没有节点一直空闲着。
(2)某个节点上任务数目太多,资源利用率太高,怎么控制一个节点上的任务数目?
答:一个节点上运行的任务数目主要由两个因素决定,一个是NodeManager可使用的资源总量,一个是单个任务的资源需求量,比如一个NodeManager上可用资源为8 GB内存,8 cpu,单个任务资源需求量为1 GB内存,1cpu,则该节点最多运行8个任务。
NodeManager上可用资源是由管理员在配置文件yarn-site.xml中配置的,相关参数如下:
yarn.nodemanager.resource.memory-mb:总的可用物理内存量,默认是8096
yarn.nodemanager.resource.cpu-vcores:总的可用CPU数目,默认是8
对于MapReduce而言,每个作业的任务资源量可通过以下参数设置:
mapreduce.map.memory.mb:物理内存量,默认是1024
mapreduce.map.cpu.vcores:CPU数目,默认是1
注:以上这些配置属性的详细介绍可参考文章:Hadoop YARN配置参数剖析(1)—RM与NM相关参数。
默认情况,各个调度器只会对内存资源进行调度,不会考虑CPU资源,你需要在调度器配置文件中进行相关设置,具体可参考文章:Hadoop YARN配置参数剖析(4)—Fair Scheduler相关参数和Hadoop YARN配置参数剖析(5)—Capacity Scheduler相关参数。
(3)如何设置单个任务占用的内存量和CPU数目?
答:对于MapReduce而言,每个作业的任务资源量可通过以下参数设置:
mapreduce.map.memory.mb:物理内存量,默认是1024
mapreduce.map.cpu.vcores:CPU数目,默认是1
需要注意的是,默认情况,各个调度器只会对内存资源进行调度,不会考虑CPU资源,你需要在调度器配置文件中进行相关设置。
(4) 用户给任务设置的内存量为1000MB,为何最终分配的内存却是1024MB?
答:为了易于管理资源和调度资源,Hadoop YARN内置了资源规整化算法,它规定了最小可申请资源量、最大可申请资源量和资源规整化因子,如果应用程序申请的资源量小于最小可申请资源量,则YARN会将其大小改为最小可申请量,也就是说,应用程序获得资源不会小于自己申请的资源,但也不一定相等;如果应用程序申请的资源量大于最大可申请资源量,则会抛出异常,无法申请成功;规整化因子是用来规整化应用程序资源的,应用程序申请的资源如果不是该因子的整数倍,则将被修改为最小的整数倍对应的值,公式为ceil(a/b)*b,其中a是应用程序申请的资源,b为规整化因子。
以上介绍的参数需在yarn-site.xml中设置,相关参数如下:
yarn.scheduler.minimum-allocation-mb:最小可申请内存量,默认是1024
yarn.scheduler.minimum-allocation-vcores:最小可申请CPU数,默认是1
yarn.scheduler.maximum-allocation-mb:最大可申请内存量,默认是8096
yarn.scheduler.maximum-allocation-vcores:最大可申请CPU数,默认是4
对于规整化因子,不同调度器不同,具体如下:
FIFO和Capacity Scheduler,规整化因子等于最小可申请资源量,不可单独配置。
Fair Scheduler:规整化因子通过参数yarn.scheduler.increment-allocation-mb和yarn.scheduler.increment-allocation-vcores设置,默认是1024和1。
通过以上介绍可知,应用程序申请到资源量可能大于资源申请的资源量,比如YARN的最小可申请资源内存量为1024,规整因子是1024,如果一个应用程序申请1500内存,则会得到2048内存,如果规整因子是512,则得到1536内存。
(5)我们使用的是Fairscheduler,配置了多个队列,当用户提交一个作业,指定的队列不存在时,Fair Scheduler会自动创建一个新队列而不是报错(比如报错:队列XXX不存在),如何避免这种情况发生?
答:在yarn-site.xml中设置yarn.scheduler.fair.allow-undeclared-pools,将它的值配置为false(默认是true)。
(6)使用Hadoop 2.0过程中,遇到了错误,怎样排查错误?
答:从hadoop 日志入手,Hadoop日志存放位置可参考我这篇文章:Hadoop日志到底存在哪里?
前言:hadoop2.x版本和hadoop1.x版本的一个区别就是:hadoop1.x中负责资源和作业调度的是MapReduce,hadoop2.x版本后,MapReduce只专注于计算,资源和作业的调度由YARN来负责。Container是YARN里面资源分配的基本单位,具有一定的内存以及CPU资源。我们的应用在工作的时候,需要消耗内存和CPU,故当YARN收到application申请,则会根据application申请的资源,分配Container。
在YARN的NodeManager节点上,会将机器的CPU和内存的一定值抽离出来,抽离成虚拟的值,然后这些虚拟的值在根据配置组成多个Container,当application提出申请时,就会分配相应的Container资源。关于默认值我们可以查看官网,如下表所示。
参数 默认值
yarn.nodemanager.resource.memory-mb
-1
yarn.nodemanager.resource.cpu-vcores
-1
yarn.scheduler.minimum-allocation-mb
1024MB
yarn.scheduler.maximum-allocation-mb
8192MB
yarn.scheduler.minimum-allocation-vcores
1
yarn.scheduler.maximum-allocation-vcores
4
内存配置
yarn.nodemanager.resource.memory-mb默认值为-1,代表着YARN的NodeManager占总内存的80%。也就是说加入我们的机器为64GB内存,出去非YARN进程需要的20%内存,我们大概需要64*0.8≈51GB,在分配的时候,单个任务可以申请的默认最小内存为1G,任务量大的话可最大提高到8GB。
在生产场景中,简单的配置,一般情况下:yarn.nodemanager.resource.memory-mb直接设置成我们需要的值,且要是最大和最小内存需求的整数倍;(一般Container容器中最小内存为4G,最大内存为16G)
假如:64GB的机器内存,我们有51GB的内存可用于NodeManager分配,根据上面的介绍,我们可以直接将yarn.nodemanager.resource.memory-mb值为48GB,然后容器最小内存为4GB,最大内存为16GB,也就是在当前的NodeManager节点下,我们最多可以有12个容器,最少可以有3个容器。
CPU配置
此处的CPU指的是虚拟的CPU(CPU virtual core),之所以产生虚拟CPU(CPU vCore)这一概念,是因为物理CPU的处理能力的差异,为平衡这种差异,就引入这一概念。
yarn.nodemanager.resource.cpu-vcores表示能够分配给Container的CPU核数,默认配置为-1,代表值为8个虚拟CPU,推荐该值的设置和物理CPU的核数数量相同,若不够,则需要调小该值。
yarn.scheduler.minimum-allocation-vcores的默认值为1,表示每个Container容器在处理任务的时候可申请的最少CPU个数为1个。
yarn.scheduler.maximum-allocation-vcores的默认值为4,表示每个Container容器在处理任务的时候可申请的最大CPU个数为4个。
PS:以上内容是小编我学习的理解,以上所示的参数为配置过程中基本的参数,如果想配置更为合理,资源利用率更高,可参考小编转载的两篇文章,初学者,如有错误请指出,谢谢。
YARN和MapReduce的内存配置优化
YARN的memory和CPU配置详解