[
https://issues.apache.org/jira/browse/HBASE-9467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763481#comment-13763481
]
stack commented on HBASE-9467:
------------------------------
bq. Yes. But I can't say how much we would gain.
Well, there'd be a usability angle where you wouldn't have to set # of handlers
as well as we wouldn't have the silly situation where on big servers we have
300 handlers and for the most part 250 are just sitting there doing noting ("do
you have something for me to do? No? Ok, well, do you? No... Do you?..." and
so on).
Isn't the story worse than you paint?
Listener -> Readers (static N threads) -> queue (block/contend/3 different
queues) -> Handlers (static M threads) -> WAL (block/contend) -> MemStore
(block/contend) -> Responder queue (block/contend)
bq. But I've just tested that (removing this queue, Reader calling 'Call',
after having removed all the synchronization), and the difference in
performances was minimal. May be 5%. So it's not our bottleneck today.
Thanks for doing this. It is interesting it makes so little difference. If so
little, yeah, we should go dig elsewhere. What was the concurrency like in
your server? tens or hundreds of handlers/readers?
> 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
