hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Welch (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MAPREDUCE-6302) deadlock in a job between map and reduce cores allocation
Date Fri, 29 May 2015 22:55:19 GMT

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

Craig Welch commented on MAPREDUCE-6302:
----------------------------------------

[~kasha] this looks good to me overall, it would be great to have this to avoid deadlocks
as such, at least as a last resort.  I agree with [~wangda] that it would be good to be able
to disable this with a value like -1, but I think you're setting the default to not be disabled
(looks like you have 5 minutes) is the way to go - by default I think it is best to have this
active.  I actually think seconds is the right granularity here, the time factor of relevance
for this sort of activity is really not in the MS range.  I also think the naming you have
for the configuration option is fine, esp. in contrast to the other (existing) delay it makes
sense.

Do you think you could add a test or two?

> deadlock in a job between map and reduce cores allocation 
> ----------------------------------------------------------
>
>                 Key: MAPREDUCE-6302
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6302
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>    Affects Versions: 2.6.0
>            Reporter: mai shurong
>            Assignee: Karthik Kambatla
>            Priority: Critical
>         Attachments: AM_log_head100000.txt.gz, AM_log_tail100000.txt.gz, log.txt, mr-6302-prelim.patch,
queue_with_max163cores.png, queue_with_max263cores.png, queue_with_max333cores.png
>
>
> I submit a  big job, which has 500 maps and 350 reduce, to a queue(fairscheduler) with
300 max cores. When the big mapreduce job is running 100% maps, the 300 reduces have occupied
300 max cores in the queue. And then, a map fails and retry, waiting for a core, while the
300 reduces are waiting for failed map to finish. So a deadlock occur. As a result, the job
is blocked, and the later job in the queue cannot run because no available cores in the queue.
> I think there is the similar issue for memory of a queue .



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

Mime
View raw message