[
https://issues.apache.org/jira/browse/HBASE-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882167#action_12882167
]
Todd Lipcon commented on HBASE-2782:
------------------------------------
Agree, not going to sidetrack. I'll bring up my gripes re snapshot/backup/etc
in the "move meta to ZK" jira if/when it gets filed :)
Also agree that we should not special-case meta in the framework. After
sleeping on it, I continue to like option 2. All that we should have to do for
initial cut is:
1) Define an interface like CallPrioritizer that takes a call object (method
name/params) and provides a PrioritizedCall object (probably just wrapper for
Long plus the original call object)
2) Internal to RPC, change callQueue over to a priority queue, where we compare
by the call priorities. If no callprioritizer is specified, we just prioritize
on insertion time like we do now.
3) Provide default implementation which prioritizes meta requests above user
requests. Make it a configurable class so people can experiment with fancier
QOS. If this turns out to work well, we turn it on by default, otherwise we
leave the "in-order execution" as is by default.
Then we can do other stuff like "reserved handler pools" or other ways of
guaranteeing execution of high priority requests in a followup JIRA.
> QOS for META table access
> -------------------------
>
> Key: HBASE-2782
> URL: https://issues.apache.org/jira/browse/HBASE-2782
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
> Reporter: Todd Lipcon
>
> I'd like to brainstorm some ideas on how we can prioritize reads and writes
> to META above reads and writes to other tables. I've noticed that if the
> regionserver hosting META is under heavy load, then lots of other operations
> take much longer than they should. For example, I'm currently running 120
> threads of YCSB across 3 client nodes hitting a 5-node cluster. Doing a full
> scan of META (only 600 rows) takes upwards of 30 seconds in the shell, since
> all of the handler threads are tied up and there's a long RPC queue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
