Return-Path: Delivered-To: apmail-hadoop-common-user-archive@www.apache.org Received: (qmail 84230 invoked from network); 9 Jul 2010 02:32:22 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 9 Jul 2010 02:32:22 -0000 Received: (qmail 13886 invoked by uid 500); 9 Jul 2010 02:32:20 -0000 Delivered-To: apmail-hadoop-common-user-archive@hadoop.apache.org Received: (qmail 13587 invoked by uid 500); 9 Jul 2010 02:32:18 -0000 Mailing-List: contact common-user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: common-user@hadoop.apache.org Delivered-To: mailing list common-user@hadoop.apache.org Received: (qmail 13579 invoked by uid 99); 9 Jul 2010 02:32:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Jul 2010 02:32:18 +0000 X-ASF-Spam-Status: No, hits=4.4 required=10.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mp2893@gmail.com designates 209.85.216.169 as permitted sender) Received: from [209.85.216.169] (HELO mail-qy0-f169.google.com) (209.85.216.169) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Jul 2010 02:32:10 +0000 Received: by qyk32 with SMTP id 32so204723qyk.14 for ; Thu, 08 Jul 2010 19:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=a10wiMBxVgRlQ77E0ifhwuY8gqxbecyZmxT2jwM1Ls8=; b=RDppTHHaBHHtUo0eNhle0rTNLzuwPc5SDT9tHUAgROnlsc20YcJPDTuQaZyL9FHRRc ZZoZe5XNuQiFU6U2KHweHoaoQaZv8p3uwW++yDmQu3EvL+cIM+AdpQspUrFLva4LcBFT hjukH+82SSSn8w9ZLiHLCyKvnNXE1nLZbkOww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Cb0z0mSU8Y5vPkrfVoxY48gn+nXJ1HvVG1rlku+4bOinMAe/jolC+/baBJ7xIigcpF ZTavLZY9DGtsocIFKyi0DIGTXhghNGP0O6RGczUp3KuSioX+MJFnRnvNHN9SKWd2zviR fR5DjYa8aJiwszCd3AmLZ33CIwEvW7GLlxsgI= MIME-Version: 1.0 Received: by 10.224.82.145 with SMTP id b17mr4554238qal.62.1278642708988; Thu, 08 Jul 2010 19:31:48 -0700 (PDT) Received: by 10.224.54.145 with HTTP; Thu, 8 Jul 2010 19:31:48 -0700 (PDT) Date: Fri, 9 Jul 2010 11:31:48 +0900 Message-ID: Subject: Is "heap size allocation" of namenode dynamic or static? From: edward choi To: common-user@hadoop.apache.org Content-Type: multipart/alternative; boundary=000feaea1f3d76c5a9048aeb346c X-Virus-Checked: Checked by ClamAV on apache.org --000feaea1f3d76c5a9048aeb346c Content-Type: text/plain; charset=ISO-8859-1 Hi, Machines in my cluster have relatively small physical memory (4GB) I was wondering if I could reduce the heap size that namenode and jobtracker are assigned. The default heap size is 1000MB respectively, and I know that. The thing is, does that 1000MB mean maximum possible memory that namenode(or jobtracker) can use? What I mean is that does namenode start with minimum memory and increase the memory size all the way up to 1000MB depending on the job status? Or is namenode given 1000MB from the beginning so that there is no flexibility at all? If namenode and jobtracker do start with solid 1000MB then I would have to dial them down to several hundreds of mega byte since I only 4GB of memory. 2giga bytes of memory taken up just by namenode and jobtracker is too much an expense for me. My question also applies to heap size of child JVM. I know that they are originally given 200MB of heap size. I intend to increase the heap size to 512MB, but if the heap size allocation has no flexibility then I'd have to maintain the 200MB configuration. Take out the 2GB (used by namenode and jobtracker) from the total 4GB, I can have only 4 map/reduce tasks with 512MB configuration and since I have quad core CPU this would be a waste. Oh, and one last thing. I am using Hadoop streaming. I read from a book that when you are using hadoop streaming, you should allocate less heap size to child JVM. (I am not sure if it meant less than 200MB or less than 400MB) Because streaming does not allow enough memory for user's processes to run. So what is the optimal heap size for map/reduce tasks in hadoop streaming? My plan was to increase the heap size of the child JVM to 512MB. But if what the book says is true, there is no point. --000feaea1f3d76c5a9048aeb346c--