From hbase-user-return-686-apmail-hadoop-hbase-user-archive=hadoop.apache.org@hadoop.apache.org Sun Jun 08 03:19:43 2008 Return-Path: Delivered-To: apmail-hadoop-hbase-user-archive@locus.apache.org Received: (qmail 79976 invoked from network); 8 Jun 2008 03:19:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 Jun 2008 03:19:43 -0000 Received: (qmail 22812 invoked by uid 500); 8 Jun 2008 03:19:45 -0000 Delivered-To: apmail-hadoop-hbase-user-archive@hadoop.apache.org Received: (qmail 22793 invoked by uid 500); 8 Jun 2008 03:19:45 -0000 Mailing-List: contact hbase-user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hbase-user@hadoop.apache.org Delivered-To: mailing list hbase-user@hadoop.apache.org Received: (qmail 22782 invoked by uid 99); 8 Jun 2008 03:19:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Jun 2008 20:19:45 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of bryan@rapleaf.com designates 208.96.16.213 as permitted sender) Received: from [208.96.16.213] (HELO mail.rapleaf.com) (208.96.16.213) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 08 Jun 2008 03:18:49 +0000 Received: from mail.rapleaf.com (localhost.localdomain [127.0.0.1]) by mail.rapleaf.com (Postfix) with ESMTP id E4B0B12502DB for ; Sat, 7 Jun 2008 20:19:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=rapleaf.com; q=dns; s=m1; b=eJNt+ HXdUr3CCQHVB2Syd05+7+ybgm7pBzgB6GY3oGTIIqEOhWsVQME4pOGCEVIhXFFVl pvcL7ngVXXsIGL2MbJu2tzP0hQ/St9LjOcUHa9CpMs5kCsH33HsubZ7Yfb/p+Zpy 8cnyGhrXy/2XwiYlg/1aVROLqPiqeXOn7qKT/8= Received: from [192.168.1.101] (unknown [192.168.1.101]) by mail.rapleaf.com (Postfix) with ESMTP id D4DA012502D1 for ; Sat, 7 Jun 2008 20:19:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <6eb82e0806071955j2a8f2bebub49a8a5aeac56532@mail.gmail.com> References: <6eb82e0806071953h7591a7a3p21e3c8f900c91cf0@mail.gmail.com> <6eb82e0806071955j2a8f2bebub49a8a5aeac56532@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bryan Duxbury Subject: Re: re-balance regions based on avgLoad Date: Sat, 7 Jun 2008 20:19:11 -0700 To: hbase-user@hadoop.apache.org X-Mailer: Apple Mail (2.753.1) X-Virus-Checked: Checked by ClamAV on apache.org We have an issue open tracking the fact that the rebalancing code has a tendency to oscillate. I haven't had the time to look at it for a while. It definitely needs some attention. The point of checking whether the avgLoad is > 2.0 is to ensure that no rebalancing occurs before there are more regions than there are servers. It doesn't do anything in that case. -Bryan On Jun 7, 2008, at 7:55 PM, Rong-en Fan wrote: > On Sun, Jun 8, 2008 at 10:53 AM, Rong-en Fan wrote: >> I'm playing with latest hbase trunk and noticed there is a >> region close-then-assign looping. >> >> I have 3 region servers and total regions are about 108, and >> the avgLoad is 36.0, then this code in RegionManager.java: >> >> if (regionsToAssign.size() == 0) { >> // There are no regions waiting to be assigned. This is an >> opportunity >> // for us to check if this server is overloaded. >> double avgLoad = master.serverManager.getAverageLoad(); >> if (avgLoad > 2.0 && thisServersLoad.getNumberOfRegions() > >> avgLoad) { >> >> If I understand correctly, when there is no outstanding unassigned >> regions, then RegionManager tries to check whether a region server >> is overloaded by the # of loaded regions on this region server. >> Then, it seems to me that avgLoad > 2.0 is quite unrealistic under >> current calculation of "avgLoad". > > Forget to mention, under my situation, all 3 boxes are kicking regions > among them as all loaded regions > avgLoad... even after assign > some to others. > > Regards, > Rong-En Fan > >> Isn't the better way to consider system load or based on # of loaded >> regions and # of requests? >> >> Thanks, >> Rong-En Fan >>