[
https://issues.apache.org/jira/browse/HBASE-11355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-11355:
------------------------------------
Attachment: HBASE-11355-v0.patch
Attached a patch that allows you to have multiple queues and the division
between reads and writes.
The default behavior is not changed, single queue with N handlers.
by setting "ipc.server.num.callqueue" > 1 you get M queues and N handlers
(where the N is still "hbase.regionserver.handler.count")
if the num.callqueus is > 1 and you set "ipc.server.callqueue.read.share" or
"ipc.server.callqueue.write.share" you'll get the division between reads and
writes. The num handlers will be (handler.count * share) and the number of
queues (num.callqueues * share).
My code has changed the scheduler by moving the queues and thread creation in a
RpcExecutor class with a SingleQueueRpcExecutor, MuliQueueRpcExecutor,
RWQueueRpcExecutor variants. It is simpler for me since I'm experimenting with
lots of different queues for HBASE-10994 and that allows me to simply create a
different instance of the RpcExecutor without keep changing the
SimpleScheduler, but I'm open for suggestion if someone wants this stuff in
0.98 or 1.0
> a couple of callQueue related improvements
> ------------------------------------------
>
> Key: HBASE-11355
> URL: https://issues.apache.org/jira/browse/HBASE-11355
> Project: HBase
> Issue Type: Improvement
> Components: IPC/RPC, Performance
> Affects Versions: 0.99.0, 0.94.20
> Reporter: Liang Xie
> Assignee: Matteo Bertozzi
> Attachments: HBASE-11355-v0.patch
>
>
> In one of my in-memory read only testing(100% get requests), one of the top
> scalibility bottleneck came from the single callQueue. A tentative sharing
> this callQueue according to the rpc handler number showed a big throughput
> improvement(the original get() qps is around 60k, after this one and other
> hotspot tunning, i got 220k get() qps in the same single region server) in a
> YCSB read only scenario.
> Another stuff we can do is seperating the queue into read call queue and
> write call queue, we had done it in our internal branch, it would helpful in
> some outages, to avoid all read or all write requests ran out of all handler
> threads.
> One more stuff is changing the current blocking behevior once the callQueue
> is full, considering the full callQueue almost means the backend processing
> is slow somehow, so a fail-fast here should be more reasonable if we using
> HBase as a low latency processing system. see "callQueue.put(call)"
--
This message was sent by Atlassian JIRA
(v6.2#6252)
