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

Allan Yang commented on HBASE-17983:
------------------------------------

Region number on a single RegionServer should not influence performance so 
dramatically. If there is no requests going to the regions, these regions are 
just some data structure  in the memory.  They have nothing to do with 
performance. Your observation that when regions increase from 200 -> 500 -> 
1000, RT increase from 5ms -> 10ms > 100ms. That may because more region can 
lead to more concurrency. For a CPU bond request, more concurrency may decrease 
the performance at a certain point.
So, I think 'control region numbers' can't improve performance. You can tune 
some configurations to improve performance. In your case, I think decrease 
handler count will increase your performance in servers with more regions

> control region numbers when create table to improve performance
> ---------------------------------------------------------------
>
>                 Key: HBASE-17983
>                 URL: https://issues.apache.org/jira/browse/HBASE-17983
>             Project: HBase
>          Issue Type: Improvement
>          Components: Admin, Client
>    Affects Versions: 2.0.0
>            Reporter: WangYuan
>            Priority: Minor
>             Fix For: 2.0.0
>
>         Attachments: 
> HBASE-17983-control-region-numbers-when-create-table.patch
>
>
> I found that with the increasing number of regions in every RegionServer , 
> HBase read and write performance decreased, and failed to achieve the desired 
> performance. Therefore, we hope to control the number of regions in every 
> RegionServer , and add the judgment before creating tables.
> I can set up a region parameter in hbase-default.xml, 
> hbase.client.region.averageload.numbers, when the client builds a table that 
> exceeds the value of this parameter, throws an exception.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to