[
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
