YARN的capacity调度器主要配置分析
yarn中一个基本的调度单元是队列。
yarn的内置调度器:
1.FIFO先进先出,一个的简单调度器,适合低负载集群。
2.Capacity调度器,给不同队列(即用户或用户组)分配一个预期最小容量,在每个队列内部用层次化的FIFO来调度多个应用程序。
3.Fair公平调度器,针对不同的应用(也可以为用户或用户组),每个应用属于一个队列,主旨是让每个应用分配的资源大体相当。(当然可以设置权重),若是只有一个应用,那集群所有资源都是他的。 适用情况:共享大集群、队列之间有较大差别。
capacity调度器的启用:
在ResourceManager节点上的yarn-site.xml设置
Property===>yarn.resourcemanager.scheduler.class
Value=====>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler
capacity调度器的配置:
在目录$HADOOP_HOME/hadoop/etc/hadoop/capacity-scheduler.xml
修改完成后,需要执行下面的命令:
$HADOOP_YARN_HOME/bin/yarn rmadmin -refreshQueues 使功能动态生效。
capacity-scheduler.xml的配置
1.定义层级队列
<property>
<name>yarn.scheduler.capacity.root.queues</name>
<value>a,b,c</value> //root根队列下有三个子队列
<description>The queues at the this level (root is the root queue).
</description>
</property> <property>
<name>yarn.scheduler.capacity.root.a.queues</name>
<value>a1,a2</value> //root.a队列下有2个子队列
<description>The queues at the this level (root is the root queue).
</description>
</property> <property>
<name>yarn.scheduler.capacity.root.b.queues</name>
<value>b1,b2,b3</value> //root.b队列下有3个子队列
<description>The queues at the this level (root is the root queue).
</description>
</property>
2.队列的调度
如上定义了
/----------a-----------a1
-----------a2
b----------b1
----------b2
----------b3
c
这种结构的队列。
队列调度算法工作方式
- 在每一层级,队列排序是根据当前队列使用资源的占比确定的,(占比相同,根据队列全路径名排序)
- 根队列将集群容量分配给第一层父队列(a,b,c),并对每个父队列递归调度。(a,b,c三个队列容量之和为100,容量是按百分比分配的)
- 父队列下的(同层级)子队列调度同上,也按容量限制。
- 子队列下管理的多个应用程序,按照FIFO方式调度资源。
每个队列都有最大最小资源占用限制,单个用户不会占尽集群资源,后文Capacity资源分配部分会详细介绍。
3.队列的访问权限控制
配置文件 $HADOOP_HOME/hadoop/etc/hadoop/capacity-scheduler.xml
<property>
<name>yarn.scheduler.capacity.root.a.acl_submit_applications</name>
<value>user1,user2 group</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.acl_administer_queue</name>
<value>"group"</value>
</property>
配置了可以提交任务到root.a队列的用户或用户组,其他用户没有权限提交任务到这个队列。value=*表示所有用户都可以提交。
root.a队列的管理员group,有权限查看该队列所有用户提交的应用程序细节。
4.队列容量配置
<property>
<name>yarn.scheduler.capacity.root.a.capacity</name>
<value>40</value>
<description>队列a占40%</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.b.capacity</name>
<value>50</value>
<description>队列b占50%</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.c.capacity</name>
<value>10</value>
<description>队列c占10%</description>
</property>
队列容量是以百分比表示的,按照a:b:c即4:5:1的比例共享集群资源。
子队列容量配置
<property>
<name>yarn.scheduler.capacity.root.a.a1.capacity</name>
<value>30</value>
<description>队列root.a.a1占30%</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.a2.capacity</name>
<value>70</value>
<description>队列root.a.a2占70%</description>
</property>
层级结构中同层级子队列容量之和不超过100%。
容量弹性配置项
<property>
<name>yarn.scheduler.capacity.root.a.a1.maximum-capacity</name>
<value>40</value>
</property>
该设置项表示可以超出父队列容量的40%,即总容量=分配的容量*140%。(实在其他队列空闲的情况下,若是其他队列有充足的任务进行,是按照比例分配的)
5.用户级别限制
用户最小资源占用设置
<property>
<name>yarn.scheduler.capacity.root.a.a1.minimun-user-limit-percent</name>
<value>20</value>
</property>
如上配置表示一个用户最少能占用队列root.a.a1容量的20%。
随着提交任务用户数的增长,有如下情况:
1.刚开始队列空闲,只有user1提交任务后,user1独占队列。
2.user2开始提交任务,user1多占用的资源不会立即释放,等user1的Container完成任务后才分配给user2。(如果Capacity调度器的抢占功能打开,user1占用的Container会被立即杀死并分配给user2)
3.第6个用户user6提交任务后(前5个用户都有任务在执行),不会分配资源给user6,应为要保证最少资源占用20%的保障,user6会放在等待列表,等待一个或多个用户任务结束。
4.每个用户提交的任务,基于FIFO顺序调度,先提交的任务优先级高于后提交的任务。
用户容量弹性配置项
<property>
<name>yarn.scheduler.capacity.root.a.a1.user-limit-factor</name>
<value>2</value>
</property>
该配置默认值为1,表示单个用户最大可以占该队列容量的100%,为2表示单个用户最大可以占该队列容量的200%。
6.队列的状态
YARN中队列有2种状态:运行和停止。
<property>
<name>yarn.scheduler.capacity.root.a.a1.state</name>
<value>RUNNING</value>
<description>
State can be one of RUNNING or STOPPED.
</description>
</property>
7.应用程序限制
<property>
<name>yarn.scheduler.capacity.maximum-applications</name>
<value>10000</value>
<description>
特定队列最大允许应用程序总数
</description>
</property> <property>
<name>yarn.scheduler.capacity.maximum-am-resource-percent</name>
<value>0.1</value>
<description>
AppMaster占用队列资源的最大比例
</description>
</property>
若要限制指定队列,修改为yarn.scheduler.capacity.root.a.maximum-am-resource-percent和yarn.scheduler.capacity.root.a.maximum-applications
参考:
《hadoop yarn权威指南》第8章 YARN中的Capacity调度器
YARN的capacity调度器主要配置分析的更多相关文章
- Ambari和YARN的Capacity调度器,安装过程
用Spark测试YARN的资源池,测试过程中发现很多时候爆资源不够: 于是添加机器,专门用于跑spark:首先是ssh不通,原来错把71的id_psa.put文件拷贝到64上面:后来ssh通了,amb ...
- 大数据之Yarn——Capacity调度器概念以及配置
试想一下,你现在所在的公司有一个hadoop的集群.但是A项目组经常做一些定时的BI报表,B项目组则经常使用一些软件做一些临时需求.那么他们肯定会遇到同时提交任务的场景,这个时候到底如何分配资源满足这 ...
- Hadoop Capacity调度器概念及配置
在Yarn框架中,调度器是一块很重要的内容.有了合适的调度规则,就可以保证多个应用可以在同一时间有条不紊的工作.最原始的调度规则就是FIFO,即按照用户提交任务的时间来决定哪个任务先执行,但是这样很可 ...
- Hadoop 三大调度器源码分析及编写自己的调度器
如要转载,请注上作者和出处. 由于能力有限,如有错误,请大家指正. 须知: 我们下载的是hadoop-2.7.3-src 源码. 这个版本默认调度器是Capacity调度器. 在2.0.2-alph ...
- Linux 内核调度器源码分析 - 初始化
导语 上篇系列文 混部之殇-论云原生资源隔离技术之CPU隔离(一) 介绍了云原生混部场景中CPU资源隔离核心技术:内核调度器,本系列文章<Linux内核调度器源码分析>将从源码的角度剖析内 ...
- go语言调度器源代码情景分析之五:汇编指令
本文是<go调度器源代码情景分析>系列 第一章 预备知识的第4小节. 汇编语言是每位后端程序员都应该掌握的一门语言,因为学会了汇编语言,不管是对我们调试程序还是研究与理解计算机底层的一些运 ...
- go语言调度器源代码情景分析之四:函数调用栈
本文是<go调度器源代码情景分析>系列 第一章 预备知识的第3小节. 什么是栈 栈是一种“后进先出”的数据结构,它相当于一个容器,当需要往容器里面添加元素时只能放在最上面的一个元素之上,需 ...
- go语言调度器源代码情景分析之三:内存
本文是<go调度器源代码情景分析>系列 第一章 预备知识的第2小节. 内存是计算机系统的存储设备,其主要作用是协助CPU在执行程序时存储数据和指令. 内存由大量内存单元组成,内存单元大小为 ...
- go语言调度器源代码情景分析之二:CPU寄存器
本文是<go调度器源代码情景分析>系列 第一章 预备知识的第1小节. 寄存器是CPU内部的存储单元,用于存放从内存读取而来的数据(包括指令)和CPU运算的中间结果,之所以要使用寄存器来临时 ...
随机推荐
- AngularJs ng-repeat
AngularJs ng-repeat 必须注意的性能问题 AngularJs 的 ng-repeat 让我们非常方便的遍历数组生成 Dom 元素,但是使用不当也会有性能问题. 在项目中我们使用 ng ...
- 用javascript实现2048的小游戏
前段时间,看了一个视频,用javascript实现的2048小游戏,发现不难,都是一些基出的语法和简单逻辑. 整个2048游戏没有很多的数据,所有,实现起来还是很有成就感的. 先上图,简直就和原版游戏 ...
- selenium + python 部署自动化测试环境
选择selenium和python其实是怀有私心的:码两行python,熟悉熟悉. selenium优点很多,我最看重的是支持多语言,足够简单,同时支持浏览器. 实际工作中,简单实用真的太重要了 ...
- linux find命令之exec
find是我们很常用的一个Linux命令,但是我们一般查找出来的并不仅仅是看看而已,还会有进一步的操作,这个时候exec的作用就显现出来了. exec解释: -exec 参数后面跟的是command ...
- vstemplate关键点纪要
创建Visual studio项目模板 vstemplate关键点纪要 经过多次的实验,终于完美生成一个.VSIX的项目模板安装包,其中遇到不少问题与挫折,久经google/baidu/自行摸索.终于 ...
- EF POWER TOOLS由数据库逆向CODE FIRST
EF POWER TOOLS由数据库逆向CODE FIRST 前言 利用db first的开发方式有很多可供选择的方案,一种可以用ado.net实体框架模型,由向导直接生成edmx,并生成数据库上下文 ...
- Pi
Math]Pi 数学知识忘地太快,在博客记录一下pi的生成. 100 Decimal places 3.1415926535897932384626433832795028841971693993 ...
- DOM处理
DOM处理 这几天整理了一下思路,本来觉得DOM部分会有很多东西,但是忽然发现频繁使用的其实并不太多 class class处理部分主要有四个 hasClass:检查元素是否包含某个class add ...
- 获取Portal中POWL程序的APPLID
获取Portal中POWL程序的APPLID 今天做练习的时候跟 Leader 学了一招,当不知道集成在 Portal 中 POWL 程序的 APPLID 的时候,可以在类 CL_POWL_MODEL ...
- spring.net AOP配置基础
在第一篇中,我们用配置代理工厂的方式实现了面向切面记日志的功能.非常便捷的实现了AOP,但当我们需要对多个切入点配置通知的时候就需要声明多个代理工厂,这样导致配置文件内容过多,配置过程也很繁琐.spr ...