[
https://issues.apache.org/jira/browse/YARN-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694773#comment-14694773
]
Hadoop QA commented on YARN-4039:
---------------------------------
\\
\\
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | pre-patch | 17m 47s | Pre-patch trunk compilation is
healthy. |
| {color:green}+1{color} | @author | 0m 0s | The patch does not contain any
@author tags. |
| {color:red}-1{color} | tests included | 0m 0s | The patch doesn't appear
to include any new or modified tests. Please justify why no new tests are
needed for this patch. Also please list what manual steps were performed to
verify this patch. |
| {color:green}+1{color} | javac | 8m 17s | There were no new javac warning
messages. |
| {color:green}+1{color} | javadoc | 10m 22s | There were no new javadoc
warning messages. |
| {color:green}+1{color} | release audit | 0m 24s | The applied patch does
not increase the total number of release audit warnings. |
| {color:red}-1{color} | checkstyle | 0m 55s | The applied patch generated
16 new checkstyle issues (total was 145, now 161). |
| {color:green}+1{color} | whitespace | 0m 1s | The patch has no lines that
end in whitespace. |
| {color:green}+1{color} | install | 1m 28s | mvn install still works. |
| {color:green}+1{color} | eclipse:eclipse | 0m 35s | The patch built with
eclipse:eclipse. |
| {color:red}-1{color} | findbugs | 1m 38s | The patch appears to introduce 1
new Findbugs (version 3.0.0) warnings. |
| {color:red}-1{color} | yarn tests | 53m 54s | Tests failed in
hadoop-yarn-server-resourcemanager. |
| | | 95m 24s | |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hadoop-yarn-server-resourcemanager |
| Failed unit tests |
hadoop.yarn.server.resourcemanager.scheduler.capacity.TestContainerAllocation |
\\
\\
|| Subsystem || Report/Notes ||
| Patch URL |
http://issues.apache.org/jira/secure/attachment/12750224/YARN-4039.2.patch |
| Optional Tests | javadoc javac unit findbugs checkstyle |
| git revision | trunk / 40f8151 |
| checkstyle |
https://builds.apache.org/job/PreCommit-YARN-Build/8838/artifact/patchprocess/diffcheckstylehadoop-yarn-server-resourcemanager.txt
|
| Findbugs warnings |
https://builds.apache.org/job/PreCommit-YARN-Build/8838/artifact/patchprocess/newPatchFindbugsWarningshadoop-yarn-server-resourcemanager.html
|
| hadoop-yarn-server-resourcemanager test log |
https://builds.apache.org/job/PreCommit-YARN-Build/8838/artifact/patchprocess/testrun_hadoop-yarn-server-resourcemanager.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-YARN-Build/8838/testReport/ |
| Java | 1.7.0_55 |
| uname | Linux asf905.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Console output |
https://builds.apache.org/job/PreCommit-YARN-Build/8838/console |
This message was automatically generated.
> New AM instances waste resource by waiting only for resource availability
> when all available resources are already used
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: YARN-4039
> URL: https://issues.apache.org/jira/browse/YARN-4039
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: fairscheduler
> Affects Versions: 2.4.0, 2.5.0, 2.6.0, 2.7.0
> Reporter: Sadayuki Furuhashi
> Assignee: Sadayuki Furuhashi
> Attachments: YARN-4039.1.patch, YARN-4039.2.patch
>
>
> Problem:
> In FairScheduler, maxRunningApps doesn't work well if we can't predict size
> of an application in a queue because small maxRunningApps can't use all
> resources if many small applications are issued, while large maxRunningApps
> wastes resources if large applications run.
> Background:
> We're using FairScheduler. In following scenario, AM instances wastes
> resources significantly:
> * A queue has X MB of capacity.
> * An application requests 32 containers where a container requires (X / 32)
> MB of memory
> ** In this case, a single application occupies entire resource of the queue.
> * Many those applications are issued (10 applications)
> * Ideal behavior is that applications run one by one to maximize throughput.
> * However, all applications run simultaneously. As the result, AM instances
> occupy resources and prevent other tasks from starting. At worst case, most
> of resources are occupied by waiting AMs and applications progress very
> slowly.
> A solution is setting maxRunningApps to 1 or 2. However, it doesn't work well
> if following workload exists at the same queue:
> * An application requests 2 containers where a container requires (X / 32) MB
> of memory
> * Many those applications are issued (say, 10 applications)
> * Ideal behavior is that all applications run simultaneously to maximize
> concurrency and throughput.
> * However, number of applications are limited by maxRunningApps. At worst
> case, most of resources are idling.
> This problem happens especially with Hive because we can't estimate size of a
> MapReduce application.
> Solution:
> AM doesn't have to start if there are waiting resource requests because the
> AM can't grant resource requests even if it starts.
> Patch:
> I attached a patch that implements this behavior. But this implementation has
> this trade-off:
> * When AM is registered to FairScheduler, its demand is 0 because even AM
> attempt is not created. Starting this AM doesn't change resource demand of a
> queue. So, if many AMs are issued to a queue at the same time, all AMs will
> be RUNNING. But we want to prevent it.
> * When a AM starts, demand of the AM is only AM attempt. Then AM requires
> more resources. Until AM requires resources, demand of the queue is low. But
> starting AM during this time will start unnecessary AMs.
> * So, this patch doesn't start immediately when AM is registered. Instead, it
> starts AM only every continuous-scheduling-sleep-ms.
> * Setting large continuous-scheduling-sleep-ms will prevent wasting AMs. But
> increases latency.
> Therefore, this patch is enabled only if new option
> "demand-blocks-am-enabled" is true.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
