[
https://issues.apache.org/jira/browse/YARN-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15085677#comment-15085677
]
Nathan Roberts commented on YARN-1011:
--------------------------------------
bq. This is one of the reasons I was proposing the notion of a max threshold
which is less than 1 If the utilization goes to 100%, we clearly know there is
contention. Since we measure resource utilization in resource-seconds (if not,
we should update it), bursty spikes alone wouldn't take utilization over 100%.
So, we shouldn't see a utilization greater than 100%.
Just to make sure I understand. When you say max threshold < 1 are you saying
an NM could not advertise 48 vcores if there are only 24 vcores physically
available? I think we have to support going above 1.0. We already go above 1.0
on our clusters, even without this feature. What I'm thinking this feature will
allow us to do is to go significantly above 1.0, especially for resources like
memory where we have to be much more careful about not hitting 100%.
One use case that I'm really hoping this feature can support is a batch cluster
(loose SLAs) with very high utilization. For this use case, I'd like the
following to be true:
- nodes can be at 100% CPU, 100% Network, or 100% Disk for long periods of time
(several minutes). Memory could get to something like 80% before corrective
action would be required. During these periods, no containers get shot to shed
load. Nodemanagers might reduce their available resource advertised to the RM,
but nothing would need to be killed.
- Both GUARANTEED and OPPORTUNISTIC containers get their fair share of
resources. They're both drawing from the same capacity and user-limit from the
RM's point of view so I feel like they should be given their fair set of
resources on the nodes they execute on. The real point of being designated
OPPORTUNISTIC in this use case is that the NM knows which containers to kill
when it needs to shed load.
Another use case is where you have a mixture of jobs, some with tight SLAs,
some with looser SLAs. This one is mentioned in previous comments and is also
very important. It requires a different set of thresholds and a different level
of fairness controls.
So, I just think things have to be configurable enough to handle both types of
clusters.
> [Umbrella] Schedule containers based on utilization of currently allocated
> containers
> -------------------------------------------------------------------------------------
>
> Key: YARN-1011
> URL: https://issues.apache.org/jira/browse/YARN-1011
> Project: Hadoop YARN
> Issue Type: New Feature
> Reporter: Arun C Murthy
> Attachments: yarn-1011-design-v0.pdf, yarn-1011-design-v1.pdf
>
>
> Currently RM allocates containers and assumes resources allocated are
> utilized.
> RM can, and should, get to a point where it measures utilization of allocated
> containers and, if appropriate, allocate more (speculative?) containers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
