Yarn 资源调优、Yarn 三种调度器
Yarn的资源调优
环境:服务器内存128G 、16物理core 资源调优如下:
-
一般情况下装完CentOS,消耗内存1G
-
系统预留15%-20%内存(包含装CentOS的部分),以防全部使用导致系统夯住 和 oom-kill事件,或者给未来部署组件预留部分空间(128*20%=25.6G==26G)
-
假设该节点只有NN和DN进程,余下内存为: 128-26=102G
-
分配DN进程(自身)2G,分配给NM进程(自身)4G,余102-2-4=96G 可供计算使用
container内存的分配
-
yarn.nodemanager.resource.memory-mb 96G 设置可调度的计算最大内存为96G
-
yarn.scheduler.minimum-allocation-mb 1G 极限情况下,有96个container 每个container内存1G
-
yarn.scheduler.maximum-allocation-mb 96G 极限情况下,只有1个container 其内存为96G
container的内存会自动增加,默认1G递增,那么container的个数的范围: 1-96个
container物理核分配 (物理核:虚拟核 =1:2 ==>16:32)
-
yarn.nodemanager.resource.cpu-vcores 32个
-
yarn.scheduler.minimum-allocation-vcores 1个 极限情况下,有32个container
-
yarn.scheduler.maximum-allocation-vcores 32个 极限情况下,只有1个container
-
container的物理核会自动增加,默认1个递增,那么container的个数的范围: :1-32个
关键: cloudera公司推荐,一个container的vcore最好不要超过5,那么我们设置4
yarn.scheduler.maximum-allocation-vcores 4 极限情况下,只有8个container
综合memory+vcore的分配
一共有32个vcore,一个container的vcore设置为4个,那么分配container一共有8个
根据container个数重新分配物理核
-
yarn.nodemanager.resource.cpu-vcores 32个
-
yarn.scheduler.minimum-allocation-vcores 1个
-
yarn.scheduler.maximum-allocation-vcores 4个 设置为4个,则极限情况下container 8个
根据物理核重新分配内存
-
yarn.nodemanager.resource.memory-mb 96G 总内存数
-
yarn.scheduler.minimum-allocation-mb 1G 每个container最小内存
-
yarn.scheduler.maximum-allocation-mb 12G 根据计算的container 8个设置最大内存为12G
分配后的每个container的vcore是4个,内存大小是12G,当然当spark计算时内存不够大,这个参数肯定要调大,那么这种理想化的设置个数必然要打破,参数的选择需要以memory为主。
假如 256G内存 56core,请问参数如何设置 ??
首先减去系统内存开销和其他进程开销,
-
系统开销: 256*0.2=52G
-
DN开销: 2G
-
NM开销: 4G
-
Hbase开销: 暂无
-
剩余内存容量为: 256-52-2-4=198G
-
确定每个container的物理核数量是4个,这里56个vcore可得到56/4=14个container容器
-
确定了最多分配14个container容器,每个容器的内存应该分配的容量是: 198/14==>14G
那么每个container的最大核数设置4,最大内存数设置14G
假如该节点还有组件,比如hbase regionserver进程,那么该如何设置?
这里需要将我们的Hbase 的regionserver的容量减去,然后再重新计算上面的值即可。
所有的配置信息在yarn-default.xml文件中
参数设置流程:建议vcore 4个 ===> 总vcore/4=container 个数 ==> 总内存/container个数得memory
内存参数默认值:
key | value | default |
---|---|---|
yarn.nodemanager.resource.memory-mb | -1 | 可以分配给容器的物理内存总量(以MB为单位) |
yarn.scheduler.minimum-allocation-mb | 1024 | RM上每个container请求的最小分配 |
yarn.scheduler.maximum-allocation-mb | 8192 | RM上每个container请求的最大分配 |
核数参数默认值:
key | value | default |
---|---|---|
yarn.nodemanager.resource.cpu-vcores | -1 | 可以为container分配的vcore总数量 |
yarn.scheduler.minimum-allocation-vcores | 1 | RM上每个container请求的最小虚拟CPU核心分配 |
yarn.scheduler.maximum-allocation-vcores | 4 | RM上每个container请求的最大虚拟CPU核心分配 |
Yarn的三种调度器
Apache hadoop2.x的默认调度器是Capacity Scheduler(计算调度器)
CDH的默认调度器是Fair Scheduler(公平调度器)
Yarn三种调度策略对比
在Yarn中有三种调度器可以选择:FIFO Scheduler ,Capacity Scheduler,FairScheduler。
FIFO Scheduler
FIFO Scheduler把应用按提交的顺序排成一个队列,这是一个先进先出队列,在进行资源分配的时候,先给队列中最头上的应用进行分配资源,待最头上的应用需求满足后再给下一个分配,以此类推。
FIFO Scheduler是最简单也是最容易理解的调度器,也不需要任何配置,但它并不适用于共享集群。大的应用可能会占用所有集群资源,这就导致其它应用被阻塞。在共享集群中,更适合采用Capacity Scheduler或Fair Scheduler,这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。从图中可以看出,在FIFO 调度器中,小任务会被大任务阻塞。
Capacity Scheduler
而对于Capacity调度器,有一个专门的队列用来运行小任务,但是为小任务专门设置一个队列会预先占用一定的集群资源,这就导致大任务的执行时间会落后于使用FIFO调度器时的时间。
Fair Scheduler
在Fair调度器中,我们不需要预先占用一定的系统资源,Fair调度器会为所有运行的job动态的调整系统资源。如上图所示,当第一个大job提交时,只有这一个job在运行,此时它获得了所有集群资源;当第二个小任务提交后,Fair调度器会分配一半资源给这个小任务,让这两个任务公平的共享集群资源。
需要注意的是,在上图Fair调度器中,从第二个任务提交到获得资源会有一定的延迟,因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源,大任务又获得了全部的系统资源。最终的效果就是Fair调度器即得到了高的资源利用率又能保证小任务及时完成。
Yarn 常用命令:
yarn application -kill