[
https://issues.apache.org/jira/browse/YARN-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081374#comment-15081374
]
Carlo Curino commented on YARN-4003:
------------------------------------
The way I think about {{RM scheduling bandwidth}} is like yet another
_orthogonal_ resource (such as CPU/memory) that you control per-queue. So yes,
you can define a max-capacity for all resources, including {{RM scheduling
bandwidth}}. But to be clear, you can have lots of CPU/memory and little RM
scheduling bandwidth (e.g., for services), or viceversa (e.g., for queues
running many small jobs with lots of short-lived tasks). So the limits on
CPU/memory should not in principle affect RM scheduling bandwith. Practically,
you will need to devote at least some of your CPU/memory to run AMs . Again
this is less true as we move to federation (YARN-2915) as there can be one RM
running the AM, but many other RMs will see this as unmanaged AMs.
> 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)