Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase >> mail # user >> HBase Client Performance Bottleneck in a Single Virtual Machine


+
Michael.Grundvig@... 2013-11-04, 03:46
+
Sriram Ramachandrasekaran... 2013-11-04, 04:11
+
Michael.Grundvig@... 2013-11-04, 05:43
+
Sriram Ramachandrasekaran... 2013-11-04, 05:52
+
lars hofhansl 2013-11-04, 05:26
+
Michael.Grundvig@... 2013-11-04, 05:36
+
lars hofhansl 2013-11-04, 18:02
+
Michael.Grundvig@... 2013-11-04, 18:32
+
Sriram Ramachandrasekaran... 2013-11-04, 05:43
+
Michael.Grundvig@... 2013-11-04, 05:51
+
Sriram Ramachandrasekaran... 2013-11-04, 05:59
+
Anoop John 2013-11-04, 06:06
+
Anoop John 2013-11-04, 05:58
+
Vladimir Rodionov 2013-11-04, 18:50
+
Michael.Grundvig@... 2013-11-04, 19:00
+
lars hofhansl 2013-11-05, 01:16
+
lars hofhansl 2013-11-05, 01:55
+
Vladimir Rodionov 2013-11-05, 02:41
+
Michael.Grundvig@... 2013-11-05, 14:43
+
lars hofhansl 2013-11-05, 15:46
+
Michael.Grundvig@... 2013-11-05, 16:35
+
lars hofhansl 2013-11-05, 16:45
+
lars hofhansl 2013-11-06, 19:09
+
Vladimir Rodionov 2013-11-06, 19:43
+
Vladimir Rodionov 2013-11-06, 19:56
Copy link to this message
-
Re: HBase Client Performance Bottleneck in a Single Virtual Machine
Usually in hbase-site.xml.  When the lads say 'on the client', they usually
mean the hbase-site.xml the client reads when it starts up (the
hbase-site.xml that is in the conf directory that it is pointing to on
startup).

St.Ack
On Tue, Nov 5, 2013 at 6:43 AM, <[EMAIL PROTECTED]> wrote:

> Thanks for the input, we'll do some more testing on this today. Where do
> these settings get made? In the configuration used to create the pool or
> somewhere else? It appears hbase-site.xml "on the client" but we have
> nothing like that so I think I'm misunderstanding something. Thanks!
>
> -Mike
>
>
> -----Original Message-----
> From: Vladimir Rodionov [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 04, 2013 8:41 PM
> To: [EMAIL PROTECTED]; lars hofhansl
> Subject: RE: HBase Client Performance Bottleneck in a Single Virtual
> Machine
>
> One more: "hbase.ipc.client.tcpnodelay" set to true. It is worth trying as
> well.
>
> Best regards,
> Vladimir Rodionov
> Principal Platform Engineer
> Carrier IQ, www.carrieriq.com
> e-mail: [EMAIL PROTECTED]
>
> ________________________________________
> From: lars hofhansl [[EMAIL PROTECTED]]
> Sent: Monday, November 04, 2013 5:55 PM
> To: [EMAIL PROTECTED]; lars hofhansl
> Subject: Re: HBase Client Performance Bottleneck in a Single Virtual
> Machine
>
> Here're one more thing to try. By default each HConnection will use a
> single TCP connection to multiplex traffic to each region server.
>
> Try setting hbase.client.ipc.pool.size on the client to something > 1.
>
> -- Lars
>
>
>
> ________________________________
>  From: lars hofhansl <[EMAIL PROTECTED]>
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Sent: Monday, November 4, 2013 5:16 PM
> Subject: Re: HBase Client Performance Bottleneck in a Single Virtual
> Machine
>
>
> No. This is terrible.
> If you can, please send a jstack and do some profiling. Is there an easy
> way to reproduce this with just a single RegionServer?
> If so, I'd offer to do some profiling.
>
> Thanks.
>
>
> -- Lars
>
>
>
> ________________________________
>
> From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Sent: Monday, November 4, 2013 11:00 AM
> Subject: RE: HBase Client Performance Bottleneck in a Single Virtual
> Machine
>
>
> Not yet, this is just a load test client. It literally does nothing but
> create threads to talk to HBase and run 4 different calls. Nothing else is
> done in the app at all.
>
> To eliminate even more of our code from the loop, we just tried removing
> our connection pool entirely and just using a single connection per thread
> - no improvement. Then we tried creating the HTableInterface (all calls are
> against the same table) at the time of connection creation. The means
> thread to connection to table interface were all at 1 to 1 and not being
> passed around. No performance improvement.
>
> Long story short, running a single thread it's fast. Start multithreading,
> it starts slowing down. CPU usage, memory usage, etc. are all negligible.
> The performance isn't terrible - it's probably good enough for the vast
> majority of users, but it's not good enough for our app. With one thread,
> it might take 5 milliseconds. With 10 threads all spinning more quickly (40
> milliseconds delay), the call time increases to 15-30 milliseconds. The
> problem is that at our throughput rates, that's a serious concern.
>
> We are going to fire up a profiler next to see what we can find.
>
> -Mike
>
>
>
> -----Original Message-----
> From: Vladimir Rodionov [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 04, 2013 12:50 PM
> To: [EMAIL PROTECTED]
> Subject: RE: HBase Client Performance Bottleneck in a Single Virtual
> Machine
>
> Michael, have you tried jstack on your client application?
>
> Best regards,
> Vladimir Rodionov
> Principal Platform Engineer
> Carrier IQ, www.carrieriq.com
> e-mail: [EMAIL PROTECTED]
>
> ________________________________________
+
Stack 2013-11-04, 20:11
+
Vladimir Rodionov 2013-11-04, 19:08