Return-Path: Delivered-To: apmail-hadoop-core-dev-archive@www.apache.org Received: (qmail 85243 invoked from network); 3 Feb 2009 01:22:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Feb 2009 01:22:23 -0000 Received: (qmail 47163 invoked by uid 500); 3 Feb 2009 01:22:20 -0000 Delivered-To: apmail-hadoop-core-dev-archive@hadoop.apache.org Received: (qmail 47139 invoked by uid 500); 3 Feb 2009 01:22:20 -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 47128 invoked by uid 99); 3 Feb 2009 01:22:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Feb 2009 17:22:20 -0800 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, 03 Feb 2009 01:22:19 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 9B4E5234C48D for ; Mon, 2 Feb 2009 17:21:59 -0800 (PST) Message-ID: <685263150.1233624119621.JavaMail.jira@brutus> Date: Mon, 2 Feb 2009 17:21:59 -0800 (PST) From: "Hairong Kuang (JIRA)" To: core-dev@hadoop.apache.org Subject: [jira] Updated: (HADOOP-5124) A few optimizations to FsNamesystem#RecentInvalidateSets In-Reply-To: <1219603012.1232996039795.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-5124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hairong Kuang updated HADOOP-5124: ---------------------------------- Attachment: optimizeInvalidate2.patch This patch incorporates Konstantin's first comment. As for (3), I am not clear how to evaluate the optimization. The goal of the new strategy is not to improve performance. Instead it aims to give fairness to all nodes when computing invalidation work. The current strategy always favors the ones in the beginning of the map since recentInvalidateSets is a TreeMap so it is sorted. Another flaw is that after the first node is scheduled, the node is reinserted into the map if it still has remaining blocks. Since it becomes the first node again, next call of invalidateWorkForOneNode will work on the same node again. The current strategy would work fine if recentInvalidateSets is a FIFO queue. > A few optimizations to FsNamesystem#RecentInvalidateSets > -------------------------------------------------------- > > Key: HADOOP-5124 > URL: https://issues.apache.org/jira/browse/HADOOP-5124 > Project: Hadoop Core > Issue Type: Improvement > Components: dfs > Reporter: Hairong Kuang > Assignee: Hairong Kuang > Fix For: 0.21.0 > > Attachments: optimizeInvalidate.patch, optimizeInvalidate1.patch, optimizeInvalidate2.patch > > > This jira proposes a few optimization to FsNamesystem#RecentInvalidateSets: > 1. when removing all replicas of a block, it does not traverse all nodes in the map. Instead it traverse only the nodes that the block is located. > 2. When dispatching blocks to datanodes in ReplicationMonitor. It randomly chooses a predefined number of datanodes and dispatches blocks to those datanodes. This strategy provides fairness to all datanodes. The current strategy always starts from the first datanode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.