[
https://issues.apache.org/jira/browse/HBASE-9467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763383#comment-13763383
]
Nicolas Liochon commented on HBASE-9467:
----------------------------------------
Yes.
Just that the number of handlers is not usually not that high compared to the
number of regions.
Note that the scheduler is now pluggable on trunk, so it's possible to put its
own implementation.
In theory, we should have as little handler as possible to limit the context
switches. In practise, it depends, I have conflicting results on my tests
around this. Obviously, if you can have a large number of handlers compared to
the number of regions, it's easier.
I was thinking about something like:
- there are 30 handlers total
- 50% can be used for any task, we don't do any analysis
- if we have more then 50% of these handlers used, then we ensure that the
remaining handlers are shared fairly (or prioritized).
The advantage of not doing any prioritization on the first 50% is that the
shared counters can be expensive if the queries hit the cache.
In your case, what is your configuration (number of regions / number of
handlers / write load vs. read load in cache) currently?
> write can be totally blocked temporarily by a write-heavy region
> ----------------------------------------------------------------
>
> Key: HBASE-9467
> URL: https://issues.apache.org/jira/browse/HBASE-9467
> Project: HBase
> Issue Type: Improvement
> Reporter: Feng Honghua
> Priority: Minor
>
> Write to a region can be blocked temporarily if the memstore of that region
> reaches the threshold(hbase.hregion.memstore.block.multiplier *
> hbase.hregion.flush.size) until the memstore of that region is flushed.
> For a write-heavy region, if its write requests saturates all the handler
> threads of that RS when write blocking for that region occurs, requests of
> other regions/tables to that RS also can't be served due to no available
> handler threads...until the pending writes of that write-heavy region are
> served after the flush is done. Hence during this time period, from the RS
> perspective it can't serve any request from any table/region just due to a
> single write-heavy region.
> This sounds not very reasonable, right? Maybe write requests from a region
> can only be served by a sub-set of the handler threads, and then write
> blocking of any single region can't lead to the scenario mentioned above?
> Comment?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
