hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arun C Murthy (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HADOOP-2247) Mappers fail easily due to repeated failures
Date Wed, 19 Dec 2007 19:36:43 GMT

     [ https://issues.apache.org/jira/browse/HADOOP-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Arun C Murthy updated HADOOP-2247:

    Status: Open  (was: Patch Available)

Couple of comments:

1. To kill maps:

bq. 2. (num-fetch-fail-notifications/num-reducers) >= max-allowed, here max-allowed = 0.5

should be (num-fetch-fail-notifications / *num-currently_running-reducers* ) >= max-allowed.
This is to ensure that long-tails do not hold up the job. For e.g. if we had a lost TT and
a bad map, we will need to wait too long for the last couple of reduces to finish; and hence
the idea is to use *num-currently_running-reducers*. 
For cases where the maps are long-lived and non-trivial the _max-completion-time_ of the mapper
used to gate the notifications to the JT from the reducer should help.

2. We don't need to maintain a mapping from mapId -> maxRetries, just a global variable
should work i.e. we don't need to customize it per mapId.

3. Please change all hard-coded factors (such as divide-by-two) to final variables. (I see
at least one instance: *minShuffleRunDuration / 2*)

> Mappers fail easily due to repeated failures
> --------------------------------------------
>                 Key: HADOOP-2247
>                 URL: https://issues.apache.org/jira/browse/HADOOP-2247
>             Project: Hadoop
>          Issue Type: Bug
>    Affects Versions: 0.15.0
>         Environment: 1400 Node hadoop cluster
>            Reporter: Srikanth Kakani
>            Assignee: Amar Kamat
>            Priority: Blocker
>             Fix For: 0.15.2
>         Attachments: HADOOP-2220.patch, HADOOP-2220.patch
> Related to HADOOP-2220, problem introduced in HADOOP-1158
> At this scale hardcoding the number of fetch failures to a static number: in this case
3 is never going to work. Although the jobs we are running are loading the systems 3 failures
can randomly occur within the lifetime of a map. Even fetching the data can cause enough load
for so many failures to occur.
> We believe that number of tasks and size of cluster should be taken into account. Based
on which we believe that a ratio between total fetch attempts and total failed attempts should
be taken into consideration.
> Given our experience with a task should be declared "Too many fetch failures" based on:
> failures > n /*could be 3*/ && (failures/total attempts) > k% /*could be
> Basically the first factor is to give some headstart to the second factor, second factor
then takes into account the cluster size and the task size.
> Additionally we could take recency into account, say failures and attempts in last one
hour. We do not want to make it too small.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message