[
https://issues.apache.org/jira/browse/HBASE-15249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15142935#comment-15142935
]
stack commented on HBASE-15249:
-------------------------------
bq. How about giving regions whose write requests are in the bottom 10% (can
make this configurable) ?
Above is totally arbitrary. If a region is getting 100 hits a second, thats 10%
of 1k -- you'd merge it because it is getting too little load?
bq. After some time, AMS stopped working because region normalizer merged the
regions into few big regions which were not able to serve high read / write
load. This is a big problem since the write requests flood the regions faster
than the splits can happen resulting in poor performance.
Numbers? How many regions was too little? What was the hit rate that
overwhelmed? What did the normalizer do? It merged up how many regions in how
much time?
The problem here is that the time between presplit and the load coming on was
too long? The normalizer merged up the regions before the load came on?
> Provide lower bound on number of regions in region normalizer for pre-split
> tables
> ----------------------------------------------------------------------------------
>
> Key: HBASE-15249
> URL: https://issues.apache.org/jira/browse/HBASE-15249
> Project: HBase
> Issue Type: Bug
> Reporter: Ted Yu
> Assignee: Ted Yu
> Attachments: HBASE-15249.v1.txt, HBASE-15249.v2.txt
>
>
> AMS (Ambari Metrics System) developer found the following scenario:
> Metrics table was pre-split with many regions on large cluster (1600 nodes).
> After some time, AMS stopped working because region normalizer merged the
> regions into few big regions which were not able to serve high read / write
> load.
> This is a big problem since the write requests flood the regions faster than
> the splits can happen resulting in poor performance.
> We should consider setting reasonable lower bound on region count.
> If the table is pre-split, we can use initial region count as the lower bound.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
