前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >YARN——容量调度中决定用户资源的几个参数

YARN——容量调度中决定用户资源的几个参数

作者头像
陈猿解码
发布2023-02-28 14:36:45
9760
发布2023-02-28 14:36:45
举报
文章被收录于专栏:陈猿解码

《YARN——正确理解容量调度的capacity参数》一文中提到了,决定用户资源使用上限的还有user-limit-factor,minimum-user-limit-percent等参数,本文就来聊聊这些相关的参数

  • user-limit-factor

从字面上理解为用户限制因子,其含义是单个用户可使用队列资源的倍数,即单个用户使用的资源上限为capacity配置的值乘以该系数。

例如该参数默认配置为1.0,队列capacity配置为10,那么单个用户最大也就使用10%的集群资源;如果该参数配置为2.0,队列capacity仍旧配置为10,那么单个用户最大可使用20%的资源(这里先不考虑用户权重参数)。

该参数除了作用于单个用户资源使用限制外,还作用于单个用户的AM资源使用上限,单个用户可提交任务数上限,具体计算方式也是乘以对应的基数。

例如该参数配置为0.8,队列maximum-application配置为1000时,单个用户最大能提交的用户数为800,如下图所示:

  • minimum-user-limit-percent

这个参数是最难理解的,相关的文章也是最少的。个人觉得网上甚至有些文章是很容易引起理解偏差的(不排除老的版本可能就是这么实现的)。

先来看一段网上文章的描述:

意思是将该参数设置为20,那么第一个用户提交任务时,可独享队列全部资源;当第二个用户提交任务时,两个用户各自享用队列50%的资源,以此类推;当第6个用户提交任务时,此时任务等待直到队列释放资源(才能分配资源运行)。

但实际真的是这样吗?抱着怀疑的心态进行如下测试:

如上图所示,将该参数配置为25。按照上面的解释推导,当第5个用户提交任务时,任务应该处于accept状态,直到其他用户的任务结束释放其资源。

然而,如下图所示,第5个用户提交的任务依旧可以正常运行。

那么,这个参数应当如何理解呢?还是来看看官网对该参数的描述吧。

也就是说,该参数确实会限制用户资源使用的上限,具体为队列资源除以活跃用户数和该参数配置值,两者之间取较大的那个作为单个用户资源使用上限。但该参数并不能理解为后面用户提交的任务会处于等待。

另外,该值默认为100,即不进行限制。

同时,需要注意的是:这里的队列资源并不完全就是capacity配置的值,而是根据当前队列实际已使用资源来动态调整的。

具体为:

当队列已使用资源小于capacity配置时,使用capacity配置的值作为队列资源;否则使用队列当前已使用资源作为队列资源。然后将该队列资源除以当前活跃用户数,与队列资源乘以minimum-user-limit-percent,除以100,两者取较大的作为最终用户资源使用上限。

  • weight

用户的权重,可以在队列中对指定用户设置更高或更低的权重,该用户最终可使用的资源,会在上面计算出来的用户资源使用上限基础上,再乘以权重的比例系数。没有给用户设置权重使用默认值100。

小结一下,上面三个参数,最终决定了队列中单个用户可使用资源的上限,其计算方法为:

(1)计算当前容量(currentCapacity)

假如队列当前已使用容量小于capacity配置,当前容量就等于capacity配置容量。

假如队列当前已使用容量大于等于capacity配置容量,当前容量就等于队列已使用容量。

(2)根据活跃用户权重及用户最小限制百分比计算用户资源限制

首先计算出队列中所有活跃用户的权重累加值,然后用当前容量分别除权重累加值,乘minimum-user-limit-percent再除100,取两者中的较大的那个作为用户资源使用上限值。

(3)根据用户限制因子计算用户资源限制

队列capacity容量乘以用户资源限制因子得到的值,与刚才计算出的用户资源使用上限,两者取较小的那个作为用户资源使用上限。

(4)乘以用户权重作为最终值

将上面计算出的用户资源使用上限再乘以用户的权重,就是该用户最终可使用资源上限值了。

举个例子,5个用户分别设置不同的权重,其他配置如下所示

代码语言:javascript
复制
集群总资源为27GB
资源最小分配单元为1GB
capacity=10
user-limit-factor=100
minimum-user-limit-percent=25

5个用户分别提交一个spark任务,spark使用1个driver和2个executor,任务运行情况如下图所示:

能看到这里,应该可以说明我写得还不算太差。

那么在阅读的过程中,你是否有过这样的疑问。

假如,第一个用户提交任务,使用了队列60%的资源,第二个用户再提交一个任务,按照上面的计算方式,每个用户最多使用队列50%的资源,那么对于已经使用60%资源的用户来说,资源限制岂不是不管用了?又或者说使用60%资源的用户,其提交任务占用的资源是否会进行释放,以保证达到预期效果。

这里卖个关子,感兴趣的可以自行思考下,答案在下一篇《YARN——容量调度中的资源抢占》中揭晓。

好了,本文就介绍到这里,原创不易,点赞,在看,分享是最好的支持, 谢谢~

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-07-11,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 陈猿解码 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档