hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ming.liu" <ming....@esgyn.cn>
Subject RE: coprocessor and hbase.regionserver.handler.count
Date Thu, 17 Jan 2019 07:35:28 GMT
Thanks, Stack,

I still cannot figure out the root cause. I am not familiar with thread-dumping or profiler.
Is there any reference that I can study about how to use those tools to analyze this kind
of issue?
Or is there some similar performance test that I can refer to? Maybe my test is wrong.
I just write a simple java program to get a row from a table in a loop. And by spawning this
program from 1 to 200, and check the response time.
I just observed that all resources CPU, memory,. I/O are still idle, but the avg response
time for a single request (put/get) become slower when the concurrency increasing. All the
request goes to the same region in my test. So I am trying to understand those parameters.

Thanks,
Ming

-----Original Message-----
From: Stack <stack@duboce.net> 
Sent: Thursday, January 17, 2019 3:17 AM
To: Hbase-User <user@hbase.apache.org>
Subject: Re: coprocessor and hbase.regionserver.handler.count

On Mon, Jan 14, 2019 at 5:37 PM ming.liu <ming.liu@esgyn.cn> wrote:

> Hi, all,
>
>
>
> Our application is using coprocessor to communicate with HBase, not using
> the get()/put() client API. When there are large concurrency, the
> performance is degrading very fast.
>
>
Can you figure why? Thread-dumping, profiler?


> I checked there is hbase.regionserver.handler.count which control how many
> thread in RS to handle client request. Will coprocessor use those same
> threads?
>
>
Yes. CPs decorate the existing read/write paths serviced by handlers.

S



>
>
> thanks,
>
> Ming
>
>
>
>


Mime
View raw message