[ https://issues.apache.org/jira/browse/HBASE-9467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13764010#comment-13764010 ]
stack commented on HBASE-9467: ------------------------------ bq. Basically, if the load is CPU bound (a search in a cache), having more threads than core is nearly useless It would be worse than useless? They get in the way? This sounds like good stuff [~nkeywal] Lets just do [~tlipcon] suggestion -- would be good if calls only got as far as the front door mat and not into the parlor before we sent then back to where they came from. > 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