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

Sunil G commented on YARN-4003:
-------------------------------

Hi [~curino]
bq.Assume a reservation queue R1 launches tons of AMs, and now another 
reservation queue R2 is stuck not being able to run any job
Yes, I agree that with one sudden spike of usage from a queue can make other 
queues to starve. IN this case, I agree with current solution, it can 
definitely help to overcome starvation and adhere to a limit also (if not the 
worst case).

Long term plan sounds interesting. {{RM scheduling bandwidth}} per queue is 
definitely a good metric here. I assume this metric should be less that queue 
capacity always (not max-capacity), is it so?

{{cost of scheduler bandwidth}} is a metric which was long pending. However, it 
is more like a ranking too. Like, ranking all apps based on its demand 
(resource request) rate, and compute that total cost to the queue level. RM can 
make use of this to know which queue has less cost and which has more. So in 
reservation case,  AMs can be restricted more in a queue with high cost for 
scheduler bandwidth. thoughts?

> ReservationQueue inherit getAMResourceLimit() from LeafQueue, but behavior is 
> not consistent
> --------------------------------------------------------------------------------------------
>
>                 Key: YARN-4003
>                 URL: https://issues.apache.org/jira/browse/YARN-4003
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: resourcemanager
>            Reporter: Carlo Curino
>            Assignee: Carlo Curino
>         Attachments: YARN-4003.patch
>
>
> The inherited behavior from LeafQueue (limit AM % based on capacity) is not a 
> good fit for ReservationQueue (that have highly dynamic capacity). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to