hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-4059) Preemption should delay assignments back to the preempted queue
Date Thu, 20 Aug 2015 02:49:47 GMT

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

Hadoop QA commented on YARN-4059:
---------------------------------

\\
\\
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | pre-patch |  16m 58s | Pre-patch trunk compilation is healthy. |
| {color:green}+1{color} | @author |   0m  0s | The patch does not contain any @author tags.
|
| {color:green}+1{color} | tests included |   0m  0s | The patch appears to include 2 new
or modified test files. |
| {color:green}+1{color} | javac |   7m 58s | There were no new javac warning messages. |
| {color:green}+1{color} | javadoc |   9m 57s | There were no new javadoc warning messages.
|
| {color:green}+1{color} | release audit |   0m 25s | The applied patch does not increase
the total number of release audit warnings. |
| {color:red}-1{color} | checkstyle |   0m 50s | The applied patch generated  1 new checkstyle
issues (total was 184, now 185). |
| {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 33s | The patch built with eclipse:eclipse.
|
| {color:green}+1{color} | findbugs |   1m 32s | The patch does not introduce any new Findbugs
(version 3.0.0) warnings. |
| {color:red}-1{color} | yarn tests |  53m 29s | Tests failed in hadoop-yarn-server-resourcemanager.
|
| | |  93m 15s | |
\\
\\
|| Reason || Tests ||
| Failed unit tests | hadoop.yarn.server.resourcemanager.scheduler.capacity.TestContainerAllocation
|
\\
\\
|| Subsystem || Report/Notes ||
| Patch URL | http://issues.apache.org/jira/secure/attachment/12751351/YARN-4059.3.patch |
| Optional Tests | javadoc javac unit findbugs checkstyle |
| git revision | trunk / 4e14f79 |
| checkstyle |  https://builds.apache.org/job/PreCommit-YARN-Build/8887/artifact/patchprocess/diffcheckstylehadoop-yarn-server-resourcemanager.txt
|
| hadoop-yarn-server-resourcemanager test log | https://builds.apache.org/job/PreCommit-YARN-Build/8887/artifact/patchprocess/testrun_hadoop-yarn-server-resourcemanager.txt
|
| Test Results | https://builds.apache.org/job/PreCommit-YARN-Build/8887/testReport/ |
| Java | 1.7.0_55 |
| uname | Linux asf903.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/8887/console |


This message was automatically generated.

> Preemption should delay assignments back to the preempted queue
> ---------------------------------------------------------------
>
>                 Key: YARN-4059
>                 URL: https://issues.apache.org/jira/browse/YARN-4059
>             Project: Hadoop YARN
>          Issue Type: Improvement
>            Reporter: Chang Li
>            Assignee: Chang Li
>         Attachments: YARN-4059.2.patch, YARN-4059.3.patch, YARN-4059.patch
>
>
> When preempting containers from a queue it can take a while for the other queues to fully
consume the resources that were freed up, due to delays waiting for better locality, etc.
Those delays can cause the resources to be assigned back to the preempted queue, and then
the preemption cycle continues.
> We should consider adding a delay, either based on node heartbeat counts or time, to
avoid granting containers to a queue that was recently preempted. The delay should be sufficient
to cover the cycles of the preemption monitor, so we won't try to assign containers in-between
preemption events for a queue.
> Worst-case scenario for assigning freed resources to other queues is when all the other
queues want no locality. No locality means only one container is assigned per heartbeat, so
we need to wait for the entire cluster heartbeating in times the number of containers that
could run on a single node.
> So the "penalty time" for a queue should be the max of either the preemption monitor
cycle time or the amount of time it takes to allocate the cluster with one container per heartbeat.
Guessing this will be somewhere around 2 minutes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message