Return-Path: Delivered-To: apmail-hadoop-core-dev-archive@www.apache.org Received: (qmail 37190 invoked from network); 5 May 2008 21:52:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 May 2008 21:52:21 -0000 Received: (qmail 79551 invoked by uid 500); 5 May 2008 21:52:21 -0000 Delivered-To: apmail-hadoop-core-dev-archive@hadoop.apache.org Received: (qmail 79505 invoked by uid 500); 5 May 2008 21:52:21 -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 79494 invoked by uid 99); 5 May 2008 21:52:21 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 May 2008 14:52:21 -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; Mon, 05 May 2008 21:51:35 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id D2CDF234C117 for ; Mon, 5 May 2008 14:51:55 -0700 (PDT) Message-ID: <1740409619.1210024315862.JavaMail.jira@brutus> Date: Mon, 5 May 2008 14:51:55 -0700 (PDT) From: "dhruba borthakur (JIRA)" To: core-dev@hadoop.apache.org Subject: [jira] Commented: (HADOOP-3248) Improve Namenode startup performance In-Reply-To: <1129580591.1208196184949.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-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594355#action_12594355 ] dhruba borthakur commented on HADOOP-3248: ------------------------------------------ Konstantin: Ok, i will change the size of bufStore as you suggsted. Nicholas: Isn't it better to keep the serialization of PermissionStatus inside PermissionStatus.java rather than putting it into INode.java? thanks. dhruba > Improve Namenode startup performance > ------------------------------------ > > Key: HADOOP-3248 > URL: https://issues.apache.org/jira/browse/HADOOP-3248 > Project: Hadoop Core > Issue Type: Bug > Components: dfs > Reporter: girish vaitheeswaran > Assignee: dhruba borthakur > Attachments: fastRestarts.patch, fastRestarts.patch, fastRestarts2.patch, fastRestarts3.patch, fastRestarts3.patch, FSImage.patch > > > One of the things that would need to be addressed as part of Namenode scalability is the HDFS recovery performance especially in scenarios where the number of files is large. There are instances where the number of files are in the vicinity of 20 million and in such cases the time taken for namenode startup is prohibitive. Here are some benchmark numbers on the time taken for namenode startup. These times do not include the time to process block reports. > Default scenario for 20 million files with the max java heap size set to 14GB : 40 minutes > Tuning various java options such as young size, parallel garbage collection, initial java heap size : 14 minutes > As can be seen, 14 minutes is still a long time for the namenode to recover and code changes are required to bring this time down further. To this end some prototype optimizations were done to reduce this time. Based on some timing analysis saveImage and loadFSImage where the primary methods that were consuming most of the time. Most of the time was being spent on doing object allocations. The goal of the optimizations is to reduce the number of memory allocations as much as possible. > Optimization 1: saveImage() > ====================== > Avoid allocation of the UTF8 object. > Old code > ======= > new UTF8(fullName).write(out); > New Code > ======== > out.writeUTF(fullName) > Optimization 2: saveImage() > ====================== > Avoid object allocation of the PermissionStatus Object and the FsPermission object. This is to be done for Directories and for files. > Old code > ======= > fileINode.getPermissionStatus().write(out) > New Code > ========= > out.writeBytes(fileINode.getUserName()) > out.writeBytes(fileINode.getGroupName()) > out.writeShort(fileINode.getFsPermission().toShort()) > Optimization 3 > ============ > loadImage() could use the same mechanism where we would avoid allocating the PermissionStatus object and the FsPermission object. > Optimization 4 > ============ > A hack was tried out to avoid the cost of object allocation from saveImage() where the fullName was being constructed using string concatenation. This optimization also helped improve performance > Overall these optimizations helped bring down the overall startup time down to slightly over 7 minutes. Most of all the remaining time is now spent in loadFSImage() since we allocate the INode and INodeDirectory objects. Any further optimizations will need to focus on loadFSImage() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.