Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: <56D083A1.3030608@gmail.com>
References: <1456502319439-16202.post@n5.nabble.com>
	<56D083A1.3030608@gmail.com>
Date: Fri, 26 Feb 2016 13:15:08 -0500
Message-ID: 
 <CAGUtCHr8Z3V9kB1gV2zHV8u4nM7R92bqzLRCdqYfdbprAEE_Bw@mail.gmail.com>
Subject: Re: cached connector
From: Keith Turner <keith@deenlo.com>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=047d7b163515800694052cb047d2

--047d7b163515800694052cb047d2
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 26, 2016 at 11:56 AM, Josh Elser <josh.elser@gmail.com> wrote:

> z11373 wrote:
>
>> My questions:
>> 1. Since I haven't killed that service instance yet, is it possible to
>> debug
>> and find out the culprit? 100x slower is too much. Is that expected? What
>> could be causing the slowness?
>>
>
> No, definitely not expected.
>
> 2. This makes me think caching Accumulo connector may not be a good idea.
>> Current implementation is the cache got refreshed if there's exception.
>> Slow
>> read won't trigger exception, so it stays in the cache. Is it recommended
>> to
>> not caching the Accumulo connector?
>>
>
> I don't think we have the means to tell you what went wrong, but perhaps
> we can help you find some clues. The Connector has some internal
> synchronization, but I would not have thought caching a Connector would
> have such negative impact -- sounds like a bug.
>
> * Try attaching a profiler to your service (e.g. Java Mission Control,
> YourKit). These can help you connect to your running service and figure out
> what is taking a long time.
> * You can also go the "low-tech" route and take a few stackdumps (e.g.
> `kill -3 <pid>` or `jstack`) on your service to see get an idea of where it
> is spending time.
> * Take a heap dump of the service (e.g. `jmap`). Perhaps there is a lot of
> garbage sitting on the heap not being collected or there's a memory leak.
>

There is also jstat, it can help you determine if the process is spending a
lot of time on GC.

--047d7b163515800694052cb047d2--