Hadoop YARN同时支持内存和CPU两种资源的调度
- 在YARN中,资源管理由ResourceManager和NodeManager共同完成,其中ResourceManager中的调度器负责资源的分配,而NodeManager则负责资源的供给和隔离。ResourceManager将某个NodeManager上资源分配给任务(这就是所谓的“资源调度”)后,NodeManager需按照要求为任务提供相应的资源,甚至保证这些资源应具有独占性,为任务运行提供基础的保证,这就是所谓的资源隔离;
- 内存资源决定任务的生死,如果内存不够,任务可能会运行失败;
- CPU资源决定任务运行的快慢,不会对生死产生影响;
总体
NameNode 的 Java 堆栈大小 (2G)
Secondary NameNode 的 Java 堆栈大小 (2G)
DataNode 的 Java 堆栈大小 (1G)
ResourceManager 的 Java 堆栈大小(字节)(1G)
NodeManager 的 Java 堆栈大小(字节)(1G)
一、yarn-site.xml
#1:for RM,该节点可使用的物理内存
yarn.nodemanager.resource.memory-mb=10240
#2:for container,该节点的container最大可使用的物理内存
yarn.scheduler.maximum-allocation-mb=10240
#一个container初始化时默认的大小为2G
yarn.scheduler.minimum-allocation-mb=2048
#3:vcore=physical-core目前推荐将该值设值为与物理CPU核数数目相同
yarn.nodemanager.resource.cpu-vcores=8
# container初始化CPU核数(默认为1核)
yarn.scheduler.minimum-allocation-vcores=8
# container最大CPU核数(默认为32核)
yarn.scheduler.maximum-allocation-vcores=256
#4:任务每使用1MB物理内存,最多可使用虚拟内存量为3.1M
yarn.nodemanager.vmem-pmem-ratio=3.1
#nodemanager物理内存检查,后台一个线程进行监控,如果超出分配值,则kill
yarn.nodemanager.pmem-check-enabled=true
#nodemanager虚拟内存检查,后台一个线程进行监控,如果超出分配值,则kill
yarn.nodemanager.vmem-check-enabled=true
#5:for aplication master mem
#2048*2,Application Master占用的内存量
yarn.app.mapreduce.am.resource.mb=4096
二、mapred-site.xml
#1:map端分配的内存大小
mapreduce.map.memory.mb=2048
#2:reduce端分配的内存大小
mapreduce.reduce.memory.mb=4096
#3:map端的堆内存大小,2048*0.8
mapreduce.map.java.opts=-Xmx1638M
#4:reduce端的堆内存大小,2048*0.8
mapreduce.reduce.java.opts=-Xmx3277M
#5:map端缓冲区所占内存大小,2048*0.4(mapreduce.map.java.opts除以2得出的,所以此处可以优化为819)
mapreduce.task.io.sort.mb=819
#6:排序时,最大合并流的文件的个数
mapreduce.task.io.sort.factor=100
#7:map端虚拟cpu的核数
mapreduce.map.cpu.vcores=2
#8:reduce端虚拟cpu的核数
mapreduce.reduce.cpu.vcores=2
#9:applicationMaster端虚拟cpu的核数
yarn.app.mapreduce.am.resource.cpu-vcores=4
三、数据平衡优化
原理:
每个DataNode的空间使用率(该节点已使用的空间和空间容量之间的百分比值)和hdfs集群的空间使用率(集群中已使用的空间和集群的空间容量之间的百分比值)非常接近,差距不超过均衡时给定的阈值,设置为10%。
设置balance节点,平衡在datanode中的文件块分布
在线上的Hadoop集群运维过程中,hadoop 的balance工具通常用于平衡hadoop集群中各datanode中的文件块分布,以避免出现部分datanode磁盘占用率高的问题(这问题也很有可能导致该节点CPU使用率较其他服务器高)。
命令:
start-balancer.sh -threshold 10%
也就是各个DataNode直接磁盘使用率偏差在10%以内。
注意:
理论上,该参数设置的越小,整个集群就越平衡,但是在线上环境中,hadoop集群在进行balance时,还在并发的进行数据的写入和删除,所以有可能无法到达设定的平衡参数值。
balance工具在运行过程中,迭代的将文件块从高使用率的datanode移动到低使用率的datanode上,每一个迭代过程中移动的数据量不超过下面两个值的较小者:10G或者指定阀值*容量,且每次迭代不超过20分钟。每次迭代结束后,balance工具将更新该datanode的文件块分布情况。
配置:
dfs.balance.bandwidthPerSec 默认设置:1048576(1 M/S),参数含义:设置balance工具在运行中所能占用的带宽,设置的过大可能会造成mr运行缓慢
注意:
1、mv命令很可怕,迁移集群的时候,如果没有迁移成功,文件还是原来的文件
2、cdh中添加balance节点,点击按钮即可进行数据平衡
四、开启uber服务
原理:
Uber模式简单地可以理解成JVM重用,该模式是Hadoop 2.x开始引入的;以Uber模式运行MR作业,所有的Map Tasks和Reduce Tasks将会在ApplicationMaster所在的容器(container)中运行,也就是说整个MR作业运行的过程只会启动AM container,因为不需要启动mapper 和 reducer containers,所以AM不需要和远程containers通信,整个过程简单了。
不是所有的MR作业都可以启用Uber模式,如果我们的MR作业输入的数据量非常小,启动Map container或Reduce container的时间都比处理数据要长,那么这个作业就可以考虑启用Uber模式运行,一般情况下,对小作业启用Uber模式运行会得到2x-3x的性能提升。
启用uber模式的要求非常严格,代码如下:
● uberEnabled:其实就是 mapreduce.job.ubertask.enable 参数的值,默认情况下为 false ;也就是说默认情况不启用Uber模式;
● smallNumReduceTasks:同理,Uber模式的作业Reduce的个数必须小于等于mapreduce.job.ubertask.maxreduces,该值默认为1;也计算说,在默认情况下,如果你想启用Uber模式,作业的Reduce个数必须小于等于1;
● smallMemory:因为作业是在AM所在的container中运行,所以要求我们设置的Map内存(mapreduce.map.memory.mb)和Reduce内存(mapreduce.reduce.memory.mb)必须小于等于AM所在容器内存大小设置(yarn.app.mapreduce.am.resource.mb);
● notChainJob:此外,处理数据的Map class(mapreduce.job.map.class)和Reduce class(mapreduce.job.reduce.class)必须不是 ChainMapper 或 ChainReducer 才行;
● isValidUberMaxReduces:目前仅当Reduce的个数小于等于1的作业才能启用Uber模式。