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 E0ED949BF for ; Thu, 7 Jul 2011 10:49:45 +0000 (UTC) Received: (qmail 43260 invoked by uid 500); 7 Jul 2011 10:49:44 -0000 Delivered-To: apmail-hbase-user-archive@hbase.apache.org Received: (qmail 42948 invoked by uid 500); 7 Jul 2011 10:49:40 -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 42940 invoked by uid 99); 7 Jul 2011 10:49:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Jul 2011 10:49:39 +0000 X-ASF-Spam-Status: No, hits=1.6 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of chensheng2010@gmail.com designates 209.85.212.41 as permitted sender) Received: from [209.85.212.41] (HELO mail-vw0-f41.google.com) (209.85.212.41) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Jul 2011 10:49:34 +0000 Received: by vws4 with SMTP id 4so856673vws.14 for ; Thu, 07 Jul 2011 03:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Q2fa0WI2VanQskkah/XXEyvS7Wb1nMDZ/8Uqa8gxV/k=; b=qU02HX8kdEcgpvlyTyyUvVP19SjrN5mW0f5khgtSnN08K4CzZS3SI/XjDtRNNNzalI C3G+4hUeL1JkiQQXldP5GskCY+YXJIOMkygI87Bi92G2YNG/J8qx0UgpBFeqBc90R+9K cuvqu3iPOOdEnt0oDUqS1obFreoadau6H3Ic4= MIME-Version: 1.0 Received: by 10.52.98.39 with SMTP id ef7mr888150vdb.88.1310035753509; Thu, 07 Jul 2011 03:49:13 -0700 (PDT) Received: by 10.52.114.164 with HTTP; Thu, 7 Jul 2011 03:49:13 -0700 (PDT) In-Reply-To: <30D4476CB62BAE4589FD646476C29CD2CE9538@SZXEML503-MBS.china.huawei.com> References: <30D4476CB62BAE4589FD646476C29CD2CE9538@SZXEML503-MBS.china.huawei.com> Date: Thu, 7 Jul 2011 18:49:13 +0800 Message-ID: Subject: Re: Is there a way to increase the compaction queue size? From: Sheng Chen To: user@hbase.apache.org Content-Type: multipart/alternative; boundary=20cf307f37cebb232904a77877e6 --20cf307f37cebb232904a77877e6 Content-Type: text/plain; charset=ISO-8859-1 Thank you very much. Actually I was trying to manage splitting manually, and to leave the compaction automatical. I really do not want to block my inserts by waiting for compactions. Is it possible to keep minor compaction working in the background, like starting a periodic job to do 'compact mytable' in the shell? Regards, Sean 2011/7/7 Zhoushuaifeng > hbase.hstore.blockingStoreFiles=Integer.MAX_VALUE > It's better not setting this to max_value. Setting this to a limited value > will help hbase to control the insert speed, and have enough time to finish > compact. Suggest to setting this to less than 20. > > hbase.hstore.max.filesize = 100G, do you mean hbase.hregion.max.filesize ? > This may be too large, if a store file too large, it will take very long > time to compact. I suggest to set this less than 8G. > > And the compaction queue size means how many regions need compaction, not > the number of files to compact. So, you have 10 regions, all need > compaction, and the compaction queue is 10. > > > Zhou Shuaifeng(Frank) > > -----Original Message----- > From: Sheng Chen [mailto:chensheng2010@gmail.com] > Sent: Thursday, July 07, 2011 3:36 PM > To: user@hbase.apache.org > Subject: Re: Is there a way to increase the compaction queue size? > > Thank you for your reply. > > No more minor compaction is going on, while there are still about 100 > HStoreFiles in each region. > I think it might because the compactionQueueSize has a maximum of 10 for a > region server (only one per region?), so after I stopped inserting and the > 10 compactions in the queue were finished, no more compaction is triggered. > > I think that "hbase.hstore.compaction.max" sets the max number of files for > one minor compaction, does it has anything to do with my problem? > > Thanks, > Sean > > 2011/7/7 Stack > > > Try setting "hbase.hstore.compaction.max" to a value other than 10, its > > default. > > > > What do you mean by 'no further minor compaction is queuing'? There > > is no more compaction going on? Are there exceptions in the log? > > > > St.Ack > > > > On Wed, Jul 6, 2011 at 10:55 PM, Sheng Chen > > wrote: > > > Hi, all, > > > I have a hbase region server of 10 regions and find the compaction > queue > > > size is always 10 at maximum. > > > After I finished inserting 1 billion records, there are still hundreds > of > > > HFiles in each region and no further minor compaction is queuing. > > > > > > My settings, > > > hbase.hstore.blockingStoreFiles=Integer.MAX_VALUE > > > hbase.hstore.compactionThreshold=3 > > > hbase.hstore.max.filesize=100G > > > > > > Is it the expected behavior? > > > Can I make the compaction queue larger in order to keep doing minor > > > compaction in the background? > > > > > > Thank you. > > > > > > Sean > > > > > > --20cf307f37cebb232904a77877e6--