On Fri, Feb 26, 2016 at 11:56 AM, Josh Elser <[email protected]> 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.
