概述
yarn.scheduler.capacity.<queue-path>.user-limit-factor：这个参数的含义是允许单个用户最多可获取的队列资源的倍数。默认值为1，确保单个用户无论集群有多空闲，永远不会占用超过队列配置的资源，即yarn.scheduler.capacity.<queue-path>.capacity的值，该参数是一个浮点值。按照这个理解，当把这个参数设置为超过1时，用户可以使用的资源将超过队列配置的资源，但应该不能超过队列配置的最大资源，否则最大资源的配置就没有意义了；如果这个参数的值小于1时，用户可以使用的资源将低于队列配置的资源。
验证
为了验证这个理解是否正确，我们通过实际测试来看。测试使用的队列是default，它的初始配置如下，配置的资源为集群的1%，最大资源是2%，user-limit-factor是1：
<property>
<name>yarn.scheduler.capacity.root.default.capacity</name>
<value>1.0</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.default.maximum-capacity</name>
<value>2.0</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.default.state</name>
<value>RUNNING</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.default.user-limit-factor</name>
<value>1.0</value>
</property>
该配置下，队列的有效资源如下：
然后执行如下任务,使用1000个map 生成10TB的数据
hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.1.3.1.0.17-1.jar\
teragen\
-Dmapred.map.tasks=1000 100000000000 /benchmarks/terasort-input
任务提交后，查看资源使用情况，如下：
任务使用的资源比例为1.1%，稍微超过了队列配置的资源。但是一直维持在这个值，不在变化。
接下来我们增加user-limit-factor的值为2，修改配置
<property>
<name>yarn.scheduler.capacity.root.default.user-limit-factor</name>
<value>2.0</value>
</property>
刷新队列后，查看资源使用情况，如下：
此时，队列使用资源正好就是队列的最大资源。然后我们继续增加user-limit-factor的值为3，修改配置
<property>
<name>yarn.scheduler.capacity.root.default.user-limit-factor</name>
<value>3.0</value>
</property>
刷新队列后，查看资源使用情况，如下：
资源使用情况没有变化，和之前使用情况一样。也就是无法超过队列的最大资源量。
接下来将这个参数的值设置为0.8， 小于1，修改配置：
<property>
<name>yarn.scheduler.capacity.root.default.user-limit-factor</name>
<value>0.8</value>
</property>
刷新队列后，查看资源使用情况（这里需要等待一段时间，资源的使用从多变少需要时间），如下：
资源使用量是0.9 % ，虽然不是 0.8% 这么精确。但是这个变化还是符合预期的。
结论
综上，可以验证对 user-limit-factor 参数的理解，在实际使用中，可能资源使用的情况没有那么精确，但是总体上是符合要求的。
另外，不知大家是否注意到了，这里对资源的限制，全部都是在内存这个维度上来进行的。如果关注一下vCore的使用情况发现，和我们想象的完全不一样。比如，按照配置，vCore的最大数是12，但在实际的计算过程中，vCore的使用达到了24。似乎最大资源的限制在vCore这个维度上是完全没有作用的。那么这是什么原因呢？
