[
https://issues.apache.org/jira/browse/HADOOP-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541731
]
Arun C Murthy commented on HADOOP-1984:
---------------------------------------
Ok, after some more thought...
Initial back-off of 2s is too aggressive - it means that it only takes 5
failures in 1minute (2 + 4 + 8 + 16 + 32 = 62s) to send a fetch-failure
notification to the JT (see HADOOP-1158) and thus doesn't sufficiently account
for transient problems faced by the tasktracker's jetty (tt on which the map
ran).
I propose we peg the starting back-off at 8s which means that it takes
approximately 4mins for one notification to be sent to the JT i.e. (8 + 16 + 32
+ 64 + 128 = 249s).
Also, we need to maintain a per-host fetch-failure count since the penaltyBox
is also maintained on a per-host basis.
> some reducer stuck at copy phase and progress extremely slowly
> --------------------------------------------------------------
>
> Key: HADOOP-1984
> URL: https://issues.apache.org/jira/browse/HADOOP-1984
> Project: Hadoop
> Issue Type: Bug
> Components: mapred
> Affects Versions: 0.16.0
> Reporter: Runping Qi
> Assignee: Amar Kamat
> Priority: Critical
> Fix For: 0.16.0
>
> Attachments: HADOOP-1984.patch
>
>
> In many cases, some reducers got stuck at copy phase, progressing extremely
> slowly.
> The entire cluster seems doing nothing. This causes a very bad long tails of
> otherwise well tuned map/red jobs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
