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运算的中间结果,之所以要使用寄存器来临时 ...
随机推荐
- RESTful API Develop
yii2 RESTful API Develop 参考文档:http://www.yiiframework.com/doc-2.0/guide-rest.html 以 DB 中的 news 表为例 ...
- 详解SpringMVC请求的时候是如何找到正确的Controller
详解SpringMVC请求的时候是如何找到正确的Controller[附带源码分析] 目录 前言 源码分析 重要接口介绍 SpringMVC初始化的时候做了什么 HandlerExecutionCha ...
- 用 MVC 5 的 EF6 Code First 入门 系列:MVC程序中实体框架的Code First迁移和部署
用 MVC 5 的 EF6 Code First 入门 系列:MVC程序中实体框架的Code First迁移和部署 这是微软官方SignalR 2.0教程Getting Started with En ...
- Plan : 破晓
题记 : 不要因为走的太远而忘记自己为什么而出发. 1. 白书(算法竞赛入门经典)看完(每一句话都要读懂) 2. 每次听完课把当天内容复习完(自习室10点以后复习) 3. 微机实验要提前预习(把实验报 ...
- Binder机制,从Java到C (7. Native Service)
1.什么是NativeService Native Service,是通过C或C++代码写出來,提供给Java进行远程调用的RemoteService.向Android开机就启动的surfacefli ...
- Linux Shell脚本攻略
-Linux Shell脚本攻略 总结的来说,这本书很实践性和实用性强,都是给的具体的例子,直接可以在终端操作实践,比单纯只看不动手务实多了,另外就是,这本书涵盖的内容也比较广,从文本操作到服务器管理 ...
- CentOS7安装Hadoop2.7流程
准备3个虚拟机节点 其实这一步骤非常简单,如果你已经完成了第2步,此时你已经准备好了第一个虚拟节点,那第二个和第三个虚拟机节点如何准备?可能你已经想明白了,你可以按第2步的方法,再分别安装两遍lin ...
- 一致性hash和虚拟节点
consistent hashing 算法的原理 consistent hashing 是一种 hash 算法,简单的说,在移除 / 添加一个 cache 时,它能够尽可能小的改变已存在key 映射关 ...
- 一种最坏情况线性运行时间的选择算法 - The missing worst-case linear-time Select algorithm in CLRS.
一种最坏情况线性运行时间的选择算法 - The missing worst-case linear-time Select algorithm in CLRS. 选择算法也就是求一个无序数组中第K大( ...
- 业务类接口在TCP,HTTP,BLL模式下的实例 设计模式混搭 附源码一份
业务类接口在TCP,HTTP,BLL模式下的实例 设计模式混搭 附源码一份 WinForm酒店管理软件--框架这篇随笔可以说是我写的最被大家争议的随笔,一度是支持和反对是一样的多.大家对我做的这个行业 ...