hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4120) isolation and allocation
Date Tue, 09 Aug 2011 18:23:27 GMT

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

Todd Lipcon commented on HBASE-4120:
------------------------------------

Ted asked me to add more detail to my comments here - sorry for being terse above. I was booted
in Windows where I don't have access to the source code.

In the patch on Review Board right now, PriorityHBaseServer inherits from Server to do the
following:
- sub out the callQueue object for a different implementation, using reflection no less. That's
totally unacceptable style in my opinion -- there has to be a better way to do it.
- uses reflection to get access to certain private methods of HBaseRegionServer - again unacceptable
- the queue that's interjected above calls getCallPriority on each Call object in order to
determine where it belongs in the queue

Instead, what I'm suggesting is:
- extend the QosFunction that we already have implemented inside HRegionServer.java with the
new logic, and move it out to its own class, since it's much more complicated with these additions.
(perhaps retain the old "simple" one as a default implementation, and construct the QosFunction
based on a config like hbase.regionserver.rpc.prioritizer or something)
- modify the existing HBaseServer implementation so that, instead of just having two queues
("high" and "low" priority) it uses a priority queue -- perhaps something like PriorityQueue<PrioritizedCall>,
where PrioritizedCall is a wrapper around the int (returned from the qosFunction) and the
original Call object, with compareTo set to compare priorities.
- keep existing behavior of having multiple pools of handlers, where some handlers are reserved
for high priority calls - this could either be generalized or left as is.

I haven't looked much at the specific code, but I think the overall structure needs to be
moved around a bit before we can get into the specific code review.

> isolation and allocation
> ------------------------
>
>                 Key: HBASE-4120
>                 URL: https://issues.apache.org/jira/browse/HBASE-4120
>             Project: HBase
>          Issue Type: New Feature
>          Components: master, regionserver
>    Affects Versions: 0.90.2, 0.90.3, 0.90.4, 0.92.0
>            Reporter: Liu Jia
>             Fix For: 0.90.3
>
>         Attachments: Design_document_for_HBase_isolation_and_allocation.pdf, Design_document_for_HBase_isolation_and_allocation_Revised.pdf,
HBase_isolation_and_allocation_user_guide.pdf, Performance_of_Table_priority.pdf, System Structure.jpg,
TablePriority.patch
>
>
> The HBase isolation and allocation tool is designed to help users manage cluster resource
among different application and tables.
> When we have a large scale of HBase cluster with many applications running on it, there
will be lots of problems. In Taobao there is a cluster for many departments to test their
applications performance, these applications are based on HBase. With one cluster which has
12 servers, there will be only one application running exclusively on this server, and many
other applications must wait until the previous test finished.
> After we add allocation manage function to the cluster, applications can share the cluster
and run concurrently. Also if the Test Engineer wants to make sure there is no interference,
he/she can move out other tables from this group.
> In groups we use table priority to allocate resource, when system is busy; we can make
sure high-priority tables are not affected lower-priority tables
> Different groups can have different region server configurations, some groups optimized
for reading can have large block cache size, and others optimized for writing can have large
memstore size. 
> Tables and region servers can be moved easily between groups; after changing the configuration,
a group can be restarted alone instead of restarting the whole cluster.
> git entry : https://github.com/ICT-Ope/HBase_allocation .
> We hope our work is helpful.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message