From core-dev-return-34921-apmail-hadoop-core-dev-archive=hadoop.apache.org@hadoop.apache.org Tue Apr 01 16:58:58 2008 Return-Path: Delivered-To: apmail-hadoop-core-dev-archive@www.apache.org Received: (qmail 95836 invoked from network); 1 Apr 2008 16:58:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Apr 2008 16:58:58 -0000 Received: (qmail 40818 invoked by uid 500); 1 Apr 2008 16:58:52 -0000 Delivered-To: apmail-hadoop-core-dev-archive@hadoop.apache.org Received: (qmail 40790 invoked by uid 500); 1 Apr 2008 16:58:52 -0000 Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: core-dev@hadoop.apache.org Delivered-To: mailing list core-dev@hadoop.apache.org Received: (qmail 40776 invoked by uid 99); 1 Apr 2008 16:58:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Apr 2008 09:58:52 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Apr 2008 16:58:09 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id C36C9234C0B2 for ; Tue, 1 Apr 2008 09:56:24 -0700 (PDT) Message-ID: <156288826.1207068984799.JavaMail.jira@brutus> Date: Tue, 1 Apr 2008 09:56:24 -0700 (PDT) From: "Devaraj Das (JIRA)" To: core-dev@hadoop.apache.org Subject: [jira] Commented: (HADOOP-3130) Shuffling takes too long to get the last map output. In-Reply-To: <988740632.1206751104225.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HADOOP-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584213#action_12584213 ] Devaraj Das commented on HADOOP-3130: ------------------------------------- bq. At least, we have to differentiate between the case of failing to fetch one map output numerous times and the case of failing to fetch a lot of different map outputs. In the first case, it is better to re-execute the map. In the second case, maybe it makes sense to consider to fail the reducer. That's how the model works in case of maps - if too many reducers complain about fetch failure for a particular map, the map is killed. The change here should be to also consider the host the map ran on otherwise we run into issues like HADOOP-2175 (https://issues.apache.org/jira/browse/HADOOP-2175?focusedCommentId=12582425#action_12582425). The problem in the reducers case is this that the numbers are hardcoded and the decision to kill is totally local. So if a reducer fails to fetch 5 unique map outputs it kills itself. This should be augmented with your suggestion on accounting for the shuffle progress. > Shuffling takes too long to get the last map output. > ---------------------------------------------------- > > Key: HADOOP-3130 > URL: https://issues.apache.org/jira/browse/HADOOP-3130 > Project: Hadoop Core > Issue Type: Bug > Reporter: Runping Qi > Attachments: HADOOP-3130.patch, shuffling.log > > > I noticed that towards the end of shufflling, the map output fetcher of the reducer backs off too aggressively. > I attach a fraction of one reduce log of my job. > Noticed that the last map output was not fetched in 2 minutes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.