在《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个用户分别设置不同的权重，其他配置如下所示

集群总资源为27GB资源最小分配单元为1GBcapacity=10user-limit-factor=100minimum-user-limit-percent=25

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

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

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

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

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

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