Region server hosting .META. isn't directly visible from master.jsp Near the top of master.jsp, you should see 'Catalog Tables' Click on .META. link, you would see which server is hosting it.
Cheers On Fri, May 13, 2011 at 7:53 AM, Thibault Dory <[email protected]>wrote: > Well my requests are fully random so I expected to see them distributed > quite evenly across all the regions. > How can I know which datanode was hosting the .META. table? I'm not running > the cluster currently so I cannot check this for the moment. > > Thanks for your input! > > Thibault Dory > > On Fri, May 13, 2011 at 4:06 PM, Ted Yu <[email protected]> wrote: > > > HBase, even the trunk version, doesn't balance load measured by read > > requests. > > Its balancer tries to put equal number of regions on each server - as > shown > > in Figure 13. > > Balancing by request count is the goal for next generation balancer. > > > > Did you remember whether client3 was also hosting .META. table ? > > > > Thanks > > > > On Fri, May 13, 2011 at 4:06 AM, Thibault Dory <[email protected] > > >wrote: > > > > > Hello, > > > > > > I have written with a few other people a paper for the ACM Symposium > > > On Cloud Computing. This paper describes the methodology, > > > infrastructure and configuration used as well as the results obtained > > > for elasticity and scalability of three noSQL databases, of wich > > > HBase. The paper can be downloaded here : > > > http://www.nosqlbenchmarking.com/wp-content/uploads/2011/05/paper.pdf< > > > > > > http://www.google.com/url?sa=D&q=http://www.nosqlbenchmarking.com/wp-content/uploads/2011/05/paper.pdf > > > > > > > > > > > > > Any feedback on the methodology used would be appreciated, we would > > > like to know if HBase is used in a "fair" way in those tests. > > > > > > We also encountered a problem with the distribution of requests among > > > region > > > servers. This problem is described in section 5.4.2 and any hints on > how > > to > > > solve this problem would be appreciated. Please note that the request > > > generation is independent of the specific database layer and that we > did > > > not > > > observe this problem for the two other databases. > > > > > > Regards, > > > > > > Thibault Dory > > > > > >
