[ 
https://issues.apache.org/jira/browse/YARN-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16252759#comment-16252759
 ] 

Zian Chen edited comment on YARN-7274 at 11/15/17 12:39 AM:
------------------------------------------------------------

I investigated this issue and figured out how we could solve this issue. 
Basically, we have sanity check within capacitiesSanityCheck which require 
capacity must be smaller than or equal to maxCapacity.  Actually, we don't need 
this constraint since we want to let absolute capacity can be equal to absolute 
max capacity in the extreme situation, but if we restrict the capacity cannot 
be bigger than maxCapacity, we will never able to achieve absCapacity equal to 
absMaxCapacity since the way to calculate absCapacity is absCap of queue x is 
multiple of capacity of x  * capacity of the parent of x * ... which will make 
absCap of queue x always smaller than absolute Max capacity of x. So, when we 
release the constriction that capacity should be smaller than or equal to 
maxCapacity, we will solve this problem.  Opinions [~leftnoteasy] 


was (Author: zian chen):
I investigated this issue and figured out how we could solve this issue. 
Basically, we have sanity check within capacitiesSanityCheck which require 
capacity must be smaller than or equal to maxCapacity.  Actually, we don't need 
this constraint since we want to let absolute capacity can be equal to absolute 
max capacity in the extreme situation, but if we restrict the capacity cannot 
be bigger than maxCapacity, we will never able to achieve absCapacity equal to 
absMaxCapacity since the way to calculate absCapacity is abs(x) = cap(x) * 
cap(x.parent) * ... which will make abs(x) always smaller than absMax(x). So, 
when we release the constriction that capacity should be smaller than or equal 
to maxCapacity, we will solve this problem.  Opinions [~leftnoteasy] 

> Ability to disable elasticity at leaf queue level
> -------------------------------------------------
>
>                 Key: YARN-7274
>                 URL: https://issues.apache.org/jira/browse/YARN-7274
>             Project: Hadoop YARN
>          Issue Type: Improvement
>          Components: capacityscheduler
>            Reporter: Scott Brokaw
>            Assignee: Zian Chen
>
> The 
> [documentation|https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html]
>  defines yarn.scheduler.capacity.<queue-path>.maximum-capacity as "Maximum 
> queue capacity in percentage (%) as a float. This limits the elasticity for 
> applications in the queue. Defaults to -1 which disables it."
> However, setting this value to -1 sets maximum capacity to 100% but I thought 
> (perhaps incorrectly) that the intention of the -1 setting is that it would 
> disable elasticity.  This is confirmed looking at the code:
> {code:java}
> public static final float MAXIMUM_CAPACITY_VALUE = 100;
> public static final float DEFAULT_MAXIMUM_CAPACITY_VALUE = -1.0f;
> ......
> maxCapacity = (maxCapacity == DEFAULT_MAXIMUM_CAPACITY_VALUE) ? 
> MAXIMUM_CAPACITY_VALUE : maxCapacity;
> {code}
> The sum of yarn.scheduler.capacity.<queue-path>.capacity for all queues, at 
> each level, must be equal to 100 but for 
> yarn.scheduler.capacity.<queue-path>.maximum-capacity this value is actually 
> a percentage of the entire cluster not just the parent queue.  Yet it can not 
> be set lower then the leaf queue's capacity setting. This seems to make it 
> impossible to disable elasticity at a leaf queue level.
> This improvement is proposing that YARN have the ability to have elasticity 
> disabled at a leaf queue level even if a parent queue permits elasticity by 
> having a yarn.scheduler.capacity.<queue-path>.maximum-capacity greater then 
> it's yarn.scheduler.capacity.<queue-path>.capacity



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to