hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Daniel Cryans <jdcry...@apache.org>
Subject Re: HBase read perfomnance and HBase client
Date Tue, 30 Jul 2013 19:06:47 GMT
That's a tough one.

One thing that comes to mind is socket reuse. It used to come up more
more often but this is an issue that people hit when doing loads of
random reads. Try enabling tcp_tw_recycle but I'm not guaranteeing
anything :)

Also if you _just_ want to saturate something, be it CPU or network,
wouldn't it be better to hit data only in the block cache? This way it
has the lowest overhead?

Last thing I wanted to mention is that yes, the client doesn't scale
very well. I would suggest you give the asynchbase client a run.


On Tue, Jul 30, 2013 at 11:23 AM, Vladimir Rodionov
<vrodionov@carrieriq.com> wrote:
> I have been doing quite extensive testing of different read scenarios:
> 1. blockcache disabled/enabled
> 2. data is local/remote (no good hdfs locality)
> and it turned out that that I can not saturate 1 RS using one (comparable in CPU power
and RAM) client host:
>  I am running client app with 60 read threads active (with multi-get) that is going to
one particular RS and
> this RS's load is 100 -150% (out of 3200% available) - it means that load is ~5%
> All threads in RS are either in BLOCKED (wait) or in IN_NATIVE states (epoll)
> I attribute this  to the HBase client implementation which seems to be not scalable (I
am going dig into client later on today).
> Some numbers: The maximum what I could get from Single get (60 threads): 30K per sec.
Multiget gives ~ 75K (60 threads)
> What are my options? I want to measure the limits and I do not want to run Cluster of
clients against just ONE Region Server?
> RS config: 96GB RAM, 16(32) CPU
> Client     : 48GB RAM   8 (16) CPU
> Best regards,
> Vladimir Rodionov
> Principal Platform Engineer
> Carrier IQ, www.carrieriq.com
> e-mail: vrodionov@carrieriq.com
> Confidentiality Notice:  The information contained in this message, including any attachments
hereto, may be confidential and is intended to be read only by the individual or entity to
whom this message is addressed. If the reader of this message is not the intended recipient
or an agent or designee of the intended recipient, please note that any review, use, disclosure
or distribution of this message or its attachments, in any form, is strictly prohibited. 
If you have received this message in error, please immediately notify the sender and/or Notifications@carrieriq.com
and delete or destroy any copy of this message and its attachments.

View raw message