Return-Path: Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Received: (qmail 78845 invoked from network); 23 Feb 2011 00:56:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 23 Feb 2011 00:56:00 -0000 Received: (qmail 49927 invoked by uid 500); 23 Feb 2011 00:56:00 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 49872 invoked by uid 500); 23 Feb 2011 00:56:00 -0000 Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hdfs-issues@hadoop.apache.org Delivered-To: mailing list hdfs-issues@hadoop.apache.org Received: (qmail 49859 invoked by uid 99); 23 Feb 2011 00:55:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Feb 2011 00:55:59 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Feb 2011 00:55:58 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id D72DE1B23F0 for ; Wed, 23 Feb 2011 00:55:38 +0000 (UTC) Date: Wed, 23 Feb 2011 00:55:38 +0000 (UTC) From: "Brian Bockelman (JIRA)" To: hdfs-issues@hadoop.apache.org Message-ID: <1644496154.9646.1298422538878.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] Commented: (HDFS-425) Major performance drop on slower machines MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HDFS-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998114#comment-12998114 ] Brian Bockelman commented on HDFS-425: -------------------------------------- This is most likely due to the kernel's buffer size. Even though HDFS performs large reads (perhaps you use the default 10MB), FUSE will transfer back to the kernel in chunks of 4kb. That is, every 4kb of reads requires 2 context switches -- the slower CPUs simply get drowned out by number of context switches. This also limits the overall throughput, even on faster CPUs. Looking in the kernel docs (found via google): http://www.mjmwired.net/kernel/Documentation/filesystems/fuse.txt It appears there is a max_read option for FUSE that might help here. Run with "-d" and see if you are getting 128KB-sized reads when FUSE. It should be possible to use hdfsRead instead of hdfsPread for sequential reads (a-la cat'ing a file). > Major performance drop on slower machines > ----------------------------------------- > > Key: HDFS-425 > URL: https://issues.apache.org/jira/browse/HDFS-425 > Project: Hadoop HDFS > Issue Type: Bug > Components: contrib/fuse-dfs > Reporter: Marc-Olivier Fleury > > When running fuse_dfs on machines that have different CPU characteristics, I noticed that the performance of fuse_dfs is very sensitive to the machine power. > The command I used was simply a cat over a rather large amount of data stored on HDFS. Here are the comparative times for the different types of machines: > Intel(R) Pentium(R) 4 CPU 2.40GHz : 2 min 40 s > Intel(R) Pentium(R) 4 CPU 3.06GHz: 1 min 50 s > 2 x Intel(R) Pentium(R) 4 CPU 3.00GHz: 0 min 40 s > 2 x Intel(R) Xeon(TM) MP CPU 3.33GHz: 0 min 28 s > Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz 0 min 15 s > I tried to find other explanations for the drop in performance, such as network configuration, or data locality, but the faster machines are the ones that are "further away" from the others considering the network configuration, and that don't run datanodes. > top shows that the CPU usage of fuse_dfs is between 80-90% on the slower machines, and about 40% on the fastest one. > This leads me to the conclusion that fuse_dfs consumes a lot of CPU resources, much more than expected. > Any help or insight concerning this issue will be greatly appreciated, since these difference actually result in days of computations for a given job. > Thank you -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira