Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 11 Jul 2011 19:47:59 +0000 (UTC)
From: "Ted Yu (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <1126087220.3778.1310413679884.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1600989987.3690.1310411159825.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-4084) Auto-Split runs only if there are
 many store files per region
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063492#comment-13063492 ] 

Ted Yu commented on HBASE-4084:
-------------------------------

I think HBASE-4081 is related to this ticket.
There was suggestion of removing the call to s.CheckSplit() in HBASE-4081.


> Auto-Split runs only if there are many store files per region
> -------------------------------------------------------------
>
>                 Key: HBASE-4084
>                 URL: https://issues.apache.org/jira/browse/HBASE-4084
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>    Affects Versions: 0.94.0
>            Reporter: John Heitmann
>
> Currently, MemStoreFlusher.flushRegion() is the driver of auto-splitting. It only decides to auto-split a region if there are too many store files per region. Since it's not guaranteed that the number of store files per region always grows above the "too many" count before compaction reduces the count, there is no guarantee that auto-split will ever happen. In my test setup, compaction seems to always win the race and I haven't noticed auto-splitting happen once.
> It appears that the intention is to have split be mutually exclusive with compaction, and to have flushing be mutually exclusive with regions badly in need of compaction, but that resulted in auto-splitting being nested in a too-restrictive spot.
> I'm not sure what the right fix is. Having one method that is essentially requestSplitOrCompact would probably help readability, and could be the ultimate solution if it replaces other calls of requestCompaction().

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira