hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Ferguson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-2) Enhance CS to schedule accounting for both memory and cpu cores
Date Sun, 21 Oct 2012 21:42:12 GMT

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

Andrew Ferguson commented on YARN-2:
------------------------------------

hi Arun,

this patch is looking GREAT! in particular, the ResourceCalculator class is super useful --
I really like it. :-)  my version, without it, is definitely much harder to follow...

before some specific feedback, I want to say that I agree that cores should be floats/fractional-units
for three reasons:
# they make sense for long-running services, which may require little CPU, but should be available
on each node, with the ease of having been scheduled by YARN.
# this gives us a fine-grained knob for implementing dynamic re-adjustment one day; ie, I
may want to increase an executing job's weight by 10%, or decrease by 15%, etc.
# the publicly released traces of resource requests & usage in Google's cluster (to my
knowledge, the only traces of their kind) include fractional amounts for CPU; having fractional
CPU requests in YARN may make it easier to translate insights from that dataset to making
better resource requests in a YARN cluster.

ok, here are some specific comments on the patch:
* *YarnConfiguration.java*: duplicate import of {{com.google.common.base.Joiner}}

* *DefaultContainer.java*: {{divideAndCeil}} explicitly uses the two-argument form of {{createResource}}
to create a resource with 0 cores, whereas other Resources created in this calculator create
resources with 1 core. this seems counter-intuitive to me, as {{divideAndCeil}} tends to result
in an _overestimate_ of resource consumption, rather than an _underestimate_. either way,
perhaps a comment would be helpful, as it is the only time this method is used this way in
the memory-only comparator

* *MultiResourceCalculator.java*: in {{compare()}}, you are looking to order the resources
by how dominant they are, and then compare by most-dominant resource, second most-dominant,
etc. ... I think the boolean flag to {{getResourceAsValue()}} doesn't make this clear. with
the flag, the question in my mind would be "wait, why would I want the non-dominant resource?".
simply having a boolean flag makes extending to three or more resources less clean. I implemented
this by treating each resource request as a vector, normalizing by clusterResources, and then
sorting the components by dominance.

* *MultiResourceCalcuator.java*, *DefaultCalculator.java*, *Resources.java*: for the {{multiplyAndNormalizeUp}}
and {{multiplyAndNormalizeDown}} methods, consider renaming the third argument to "stepping"
instead of "factor" is it's not a factor used for the multiplication, rather it's a unit of
discretization to round to ("stepping" may not be the best word, but perhaps it's closer).
just a thought...

* *CSQueueUtils.java*: extra spaces in front of {{@Lock(CSQueue.class)}}

* *CapacityScheduler.java*: in the {{allocate()}} method, there's a call to normalize the
request (after a comment about sanity checks). currently, it only normalizes the memory; I
think the patch should also normalize the number of CPU's requested, no?

* *LeafQueue.java*: in {{assignReservedContainer}} consider changing {{Resources.divide}}
to {{Resources.ratio}} when calculating {{potentialNewCapacity}} (and the current capacity).
While both calls "should" give the same result, {{ratio}} has fewer floating-point operations,
and, better yet, is semantically what is meant in this case -- we're calculating the ratio
between (used + requested) and available. Frankly, this is perhaps something to take a closer
look at (as [~vinodkv] pointed out): whether both {{divide}} and {{ratio}} are needed, and
if so, which should be used in each case.


Also, both *ContainerTokenIdentifier.java* and *BuilderUtils.java* assume that memory is the
only resource; I'm not certain they should be updated, but I wanted to mention them just in
case.

Oh, and should *yarn-default.xml* be updated with values for {{yarn.scheduler.minimum-allocaiton-cores}}
and {{yarn.scheduler.maximum-allocation-cores}} ?


Hope this helps, Arun!  depending on how the discussion of integral vs fractional cores shakes
out, I think this patch is good to go.


cheers,
Andrew
                
> Enhance CS to schedule accounting for both memory and cpu cores
> ---------------------------------------------------------------
>
>                 Key: YARN-2
>                 URL: https://issues.apache.org/jira/browse/YARN-2
>             Project: Hadoop YARN
>          Issue Type: New Feature
>          Components: capacityscheduler, scheduler
>            Reporter: Arun C Murthy
>            Assignee: Arun C Murthy
>             Fix For: 2.0.3-alpha
>
>         Attachments: MAPREDUCE-4327.patch, MAPREDUCE-4327.patch, MAPREDUCE-4327.patch,
MAPREDUCE-4327-v2.patch, MAPREDUCE-4327-v3.patch, MAPREDUCE-4327-v4.patch, MAPREDUCE-4327-v5.patch,
YARN-2-help.patch, YARN-2.patch, YARN-2.patch, YARN-2.patch
>
>
> With YARN being a general purpose system, it would be useful for several applications
(MPI et al) to specify not just memory but also CPU (cores) for their resource requirements.
Thus, it would be useful to the CapacityScheduler to account for both.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message