I hope you have configured 200+ handlers in server config and not creating a new connection in every thread. Sharing your java code, hbase version, machine configuration and hbase-site.xml may help us comment more.
Regards, Ankit Singhal On Wed, Jan 16, 2019 at 11:35 PM ming.liu <[email protected]> wrote: > 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 <[email protected]> > Sent: Thursday, January 17, 2019 3:17 AM > To: Hbase-User <[email protected]> > Subject: Re: coprocessor and hbase.regionserver.handler.count > > On Mon, Jan 14, 2019 at 5:37 PM ming.liu <[email protected]> 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 > > > > > > > > > >
