Return-Path: X-Original-To: apmail-hbase-user-archive@www.apache.org Delivered-To: apmail-hbase-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E3B251729F for ; Tue, 14 Oct 2014 11:54:25 +0000 (UTC) Received: (qmail 74757 invoked by uid 500); 14 Oct 2014 11:54:24 -0000 Delivered-To: apmail-hbase-user-archive@hbase.apache.org Received: (qmail 74684 invoked by uid 500); 14 Oct 2014 11:54:24 -0000 Mailing-List: contact user-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hbase.apache.org Delivered-To: mailing list user@hbase.apache.org Received: (qmail 74672 invoked by uid 99); 14 Oct 2014 11:54:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Oct 2014 11:54:23 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.220.170] (HELO mail-vc0-f170.google.com) (209.85.220.170) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Oct 2014 11:54:18 +0000 Received: by mail-vc0-f170.google.com with SMTP id hy10so7345434vcb.15 for ; Tue, 14 Oct 2014 04:53:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=6AdpGM9XelQOqznoiI86ofTAjFRXwWJmqF9/tD9EvME=; b=Uf+dTrK1iSJ0JoDJAadqB0WRJOHfIpNuDrIHu7ywtCPBCx9uvJSblXf9puaXVdrP91 E63G42mpMOWjRLpFY7Fe3BJ58EtGfDpELtrFcCzLtzGDGd78gfG2n1wB17x5GAwf+DjI Ai1MO03YOg7guzEKNzt958drRuMKLSUTkgZcf/JAJDQmL0hUamj0P3JrPZLQrLLShM0H OYwOz1xeNay/KTq7vd0FBt6LKzMYLwjiMF8rFRX61Wx3Tfzh7RecnG6c0kV80CdvrJ/r cuweKCRwHLco3ursvCK1xlHojnsGpkeDiND8wYFimg+KExT3rWKJw6d/41KjlFL4mn4w 4g+A== X-Gm-Message-State: ALoCoQndljsE1zJX7udbKIIVpZXIusxrULs5flpX8nSYnVYRsHKfRzPtgmoH8zXH1IpCzxjnLLio X-Received: by 10.220.87.138 with SMTP id w10mr4318267vcl.4.1413287637383; Tue, 14 Oct 2014 04:53:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.148.17 with HTTP; Tue, 14 Oct 2014 04:53:37 -0700 (PDT) In-Reply-To: <27FEA902-E00F-4BF2-9ED0-865A7C74D043@gmail.com> References: <27FEA902-E00F-4BF2-9ED0-865A7C74D043@gmail.com> From: Jean-Marc Spaggiari Date: Tue, 14 Oct 2014 07:53:37 -0400 Message-ID: Subject: Re: Too many non-used regions To: user Content-Type: multipart/alternative; boundary=047d7b3a911a978d8b050560abbd X-Virus-Checked: Checked by ClamAV on apache.org --047d7b3a911a978d8b050560abbd Content-Type: text/plain; charset=UTF-8 To reply to the question "Can big count of non-used(!!!) regions affect write/read perfomance for tables which are in use.", respons is: No. If regions are not receiving writes, memstore will not take memory from the reserved write memory area. If regions are not receiving reads, there will be no blocks cached for those tables. There will still be some memory used for the meta informations for those regions on the region servers, but this memory is not part of the memstore nor he blockcache areas and will not impact the performances of the other operations as long as you still have enough memory to store metadata of all those regions. On average, on a server, how many regions total you have, and part from that, how many get writes, how many get reads? Also, what is the configured heap size and have you change the configuration for the block cache and the memstore areas? JM 2014-10-14 6:57 GMT-04:00 Ted Yu : > If cluster restarts, master still needs to assign such regions. > This would affect MTTR. > > Otherwise in a stable cluster, they shouldn't consume much resource. > > Cheers > > On Oct 14, 2014, at 3:45 AM, Serega Sheypak > wrote: > > > Ok, I got. > > And in general, region which has no R/W requests doesn't consume ny > > resources except record in META? > > > > 2014-10-14 13:42 GMT+04:00 Ted Yu : > > > >> In 0.94, load balancer doesn't take load each region receives into > >> account. It only considers the number of regions as the sole criteria > for > >> balancing. > >> > >> Thus the high number of unused regions may cause imbalance. > >> > >> Please consider reducing unused regions. > >> > >> Cheers > >> > >> On Oct 14, 2014, at 2:33 AM, Serega Sheypak > >> wrote: > >> > >>> We are using CDH 4.6 (hbase-0.94.15+86) > >>> Regions are balanced. > >>> - Read/write request are pretty even, > >>> - count or regions per RegionServer is pretty even. > >>> - there are no "hot spots" > >>> > >>> > >>> 2014-10-14 12:50 GMT+04:00 Qiang Tian : > >>> > >>>> region unbalanced? > >>>> which hbase release? > >>>> > >>>> > >>>> On Tue, Oct 14, 2014 at 3:39 PM, Serega Sheypak < > >> serega.sheypak@gmail.com> > >>>> wrote: > >>>> > >>>>> Hi, we have 10 nodes cluster with 10HDD, 256 GB RAM and 10HDD 3TB > each. > >>>>> Suddenly we met write perfomance issues. > >>>>> > >>>>> Our workload is: > >>>>> 1. We have 100+ region table for write load. It has constant set of > >> keys > >>>>> (~6* 10^7) and we write "updates". No versions or stuff like that > >>>>> 2. We have several read-only tables, theirs size could be from 1 > egion > >> up > >>>>> to 256 regions. > >>>>> 3. We have several non-used tables theirs size could be from 1 > region > >> up > >>>>> to 256 regions. These tables are previous versions of read-only > tables. > >>>>> > >>>>> Right now each RegionServer serves >100 regions, but only half of > them > >>>> are > >>>>> active. Really nothing changed for the last few weeks, we got more > >>>> non-used > >>>>> tables, but quantity on active read-only tables is the same, single > >>>>> wirte-only table dodn't get more bytes to write. > >>>>> > >>>>> Can big count of non-used(!!!) regions affect write/read perfomance > for > >>>>> tables which are in use. > >> > --047d7b3a911a978d8b050560abbd--