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

Xiaolin Ha commented on HBASE-27962:
------------------------------------

I think this idea is to resolve the fixed ratio of handlers, but the shared 
ratio is still fixed. And what's more, shared handlers broken the isolated 
process model of reads and writes by 'Shared handler could run all the three 
kinds of requests'.  This is a very serious problem when there are huge 
requests, since shared handlers will make all types of requests blocked, though 
it has a float ratio and not all the whole, which will make slow requests 
problems hard to debug.

HBASE-27766 is not the same as HBASE-27962, though they are somehow similar. 
HBASE-27766 keeps the isolate model of reads and writes, and it still keeps the 
origin scan ability and only steals jobs from gets when scan handlers is iddle. 
As a result, you can not afraid of bad ratio of handlers make the resources 
unbounded, all that should be care is the ratio of reads(scan+get) and writes.

Thanks.

> Introduce an AdaptiveFastPathRWRpcExecutor to make the W/R/S separations fit 
> various workloads 
> -----------------------------------------------------------------------------------------------
>
>                 Key: HBASE-27962
>                 URL: https://issues.apache.org/jira/browse/HBASE-27962
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Yutong Xiao
>            Assignee: Yutong Xiao
>            Priority: Major
>
> We currently use the FastPathRWQueueRpcExecutor. But the numbers of 
> read/write handlers are fixed, which make the RegionServer performance not so 
> good in our prod env.
> The logic of it is described below:
>  * The basic architecture is same as FastPathRWRpcExecutor.
>  * Introduced a float shared_ratio (0, 1.0), to indicate the ratio of the 
> number of shared handlers. (for example, when we set the ratio to 0.2, if we 
> have 100 handlers, 50 for write, 25 for get, 25 for scan, there will be 10 + 
> 5 + 5 shared handlers and 40 isolated handlers for write, 20 for get and 20 
> for scan).
>  * Shared handler could run all the three kinds of requests.
>  * Shared handler will be shared only when it is idle.
>  * Shared handler is also bounded to a kind of RPCQueue, it will process the 
> requests in that queue first.
> This improvement will improve the resource utility under various workloads 
> and guarantee a level of R/W/S isolation for requests processing at the same 
> time.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to