YARN——正确理解容量调度的capacity参数
容量调度器中,配得最多的应该就是capacity和maximum-capacity了,一个是当前队列的资源容量,一个是队列可使用的最大容量。多个队列的容量之和为100。
maximum-capacity这个参数还好理解,即队列可使用资源的上限。
假如有多个队列,每个队列都将maximum-capacity的值设置成与capacity一样,意味着每个队列只能使用固定大小的资源,不能超额使用其他队列空闲资源,这样,也就可能出现资源浪费或利用率低的情况。
因此,通常该值会设置成比capacity大。例如都设置为100,也就是每个队列最大都可以使用集群的全部资源。
但既然最大都可以使用集群的全部资源,那么capacity参数的作用和意义到底是什么,该参数又是如何限制用户资源使用的。
查看了官方文档,网上也看了不少文章,始终觉得没有讲透capacity这个参数的意义,索性直接撸源码。
结合源码,并对照日志,确认了几个关键点后,对自己的结论很是自信,立马邮件同步给组内的小伙伴。
队列的capacity参数是单个用户在该队列中所能使用资源的上限。
由于允许多个不同的用户向同一个队列提交任务,因此多个用户的不同任务的资源叠加起来可以超过capacity,但是不能超过maximum-capacity。
然而,没过多久,就收到了同事的答复邮件,并附带如下图示:队列配置10%的资源,用户提交了一个任务,使用的资源远超10%!
收到邮件,瞬间觉得脸已被打肿,但是之前研究相关源码,确定应该是会限制的啊,难道是哪个细节没注意到,代码走了其他分支?
带着疑问再次走读相关代码,并进行一系列测试,发现该现象是可以解释的,之前给出的结论也仍旧还是成立的。
当前集群的总资源为12GB,队列容量设置为10%,因此该队列上,单个用户理论上资源使用的上限为:
1228.8MB =
注:该队列的父队列为root,如果父队列不是root,则需要继续乘父队列的容量百分比。
由于配置的集群资源分配最小单位为1024MB,因此需要向上取整,即2048MB。也就是单个用户使用的资源上限为2048MB。
当spark任务的driver启动时(申请的资源为2048MB),当前队列中,该用户已使用的资源为0,未超过上限,因此可以为其分配资源,即driver可以成功启动。
driver启动后继续申请启动两个executor,每个executor申请分配2048MB。yarn调度时,发现该用户当前已使用资源为2048MB(为driver分配的资源),仍旧未超过上限,因此继续为一个executor分配了资源。但轮到第二个executor时,该用户当前已使用的资源变为了4096MB,超过了上限,因此没有为该executor分配资源。
也就是说:虽然队列容量配置的是10%,但并不是严格按照10%来限制,即允许超额使用。只要用户当前已使用资源没有超过上限,就可以继续分配(即便分配后会超过上限);但一旦当前已使用的资源超过了上限时,则不能再继续分配资源。
为了验证上面的结论,再进行如下测试:队列的容量仍旧配置为10%,同时将AM资源使用限制调高(maximum-am-resource-percent),防止因AM资源受限出现干扰。
先提交一个spark任务,情况和上面的情况一样,再次提交一个任务时,第二个任务始终处于ACCEPT状态,spark任务的driver都没有进行资源分配。
同时,从界面上可以看到任务的诊断信息为:超过用户资源使用上限。
在这个基础之上,切换用户,再提交一个spark任务,发现任务可以正常运行,如下图所示:
将该队列的AM资源使用限制调回到原来的值,再来进行测试,第二个任务同样处于ACCEPT状态,但界面上看到的信息则不同,提示为:超过用户AM最大使用资源。
到这里,也就验证了之前的结论是正确的了。
将上面的测试过程,相关截图,以及结论总结进行了汇总,然后邮件进行了回复,以为可以告一段落了。但是,过了一会,再次收到了邮件,回复如下:
将队列的容量设置为5%,那么理论上该队列单个用户的最大使用资源为:
614.4MB =
向上取整为1024MB,按你的结论,提交的任务应该都无法分配资源,处于ACCEPT状态才对,然而还是进行了资源的分配,如下图所示:
看到邮件后,心情很平淡,因为之前的研究过程中,已经发现了这个问题,直接贴一段代码说明:
也就是说,只要当前队列中没有任务在运行,提交任务时,即便是超过了用户可使用资源的上限,仍旧会进行资源的分配,保证有一个任务可以运行。
另外,从上面的图中,还可以看出一点,该任务只分配了2048MB,也就是driver的资源,而driver申请启动的executor均未分配到任何资源,因为当前已使用资源已经超过了上限。
【总结】
队列的capacity参数是作用于单个用户的资源使用上限,真正调度分配时只要用户已使用资源未超过上限,就可以继续分配(分配后可以超过上限)。
当然决定用户资源使用上限的还有其他参数,例如user-limit-factor,minimum-user-limit-percent等,后续文章再单独说明。
另外,整个讨论过程下来,体会到源码是不会说谎的,看源码的同时还是要多动手测试验证,才能真正做到正确理解。
好了,本文就讲到这里,原创不易,点赞,在看,分享是最好的支持, 谢谢~
本文分享自微信公众号 - hncscwc(gh_383bc7486c1a)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
禅道自动化测试框架 ZTF 发布 2.4 版本,增加测试步骤自动提取功能
大家好,禅道自动化测试框架2.4版本发布,支持在脚本的任意地方编写测试步骤和期待结果,并提供了一个extract命令用于提取这些信息。 ZTF是禅道团队自研的自动化测试框架,支持与禅道无缝集成,可将禅道用例和测试脚本进行同步,将执行结果自动提交到禅道并生成测试报告,执行失败的用例可通过命令在禅道中创建Bug。ZTF自动化测试框架实现了与Jenkins持续集成功能的打通。用户发起Jenkins构建后,通过ZTF调度执行测试脚本,结束后把单元和功能测试的结果回传给禅道,二者合作打通持续集成的闭环。 欢迎大家下载试用,并提出宝贵建议。 一、更新记录 支持在脚本的任意地方编写测试步骤和期待结果; 新增extract命令,用于提取测试步骤和期待结果; 修复了一些小的问题。 二、下载地址 ztf-win64-2.4.zip ztf-win32-2.4.zip ztf-linux-2.4.tar.gz ztf-mac-2.4.zip 项目源代码(zip) GitHub项目首页 三、帮助文档 Jenkins持续集成文档 自动化测试文档 单元测试文档 四、新功能界面展示 从代码中提取测试步骤: 1. 示...
- 下一篇
别卷了,是时候打破人工智能应用的高门槛了
提到人工智能领域,许多人将其视为一流程序员的聚集地,更有甚者,认为想要进入人工智能领域得数学好爱学习、懂交叉学科知识、有名师指导等等。 然而 AI 已经逐渐渗透在生活的许多细节中,如看图识物,图片风格化处理,智能家电的语音唤醒……这也意味着,我们需要更多 AI 领域工程师。 现在,这里就有一个学习上手并检验的最佳机会!近日,英特尔携手微软于 2021 世界地球日共同发起的“AI for Earth 英梦集结,微 AI 来战”黑客松大赛。大赛设置了开发大赛及学习挑战赛双赛道,开发大赛项目作品提交截至 6 月 15 日,学习挑战赛持续到 7 月 4 日。 参与了开发大赛的用户参与到学习挑战赛中,即有机会获得学霸奖,未提交项目作品的用户参与学习挑战赛则有机会获得优秀奖。7 月 24 日,赛事方将颁布学霸奖和优秀奖,并送上精美礼品,敬请期待! 点击下方链接查看详情: https://docs.microsoft.com/zh-cn/learn/challenges?id=d3708c4d-1181-463d-b5fa-e4a195a58c9c 迈出人工智能学习第一步 正如英特尔学习任务课程第一...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7安装Docker,走上虚拟化容器引擎之路
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS关闭SELinux安全模块
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Docker安装Oracle12C,快速搭建Oracle学习环境
- SpringBoot2全家桶,快速入门学习开发网站教程
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长