esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Engbrecht <>
Subject Re: Memory usage -> stability probs?
Date Tue, 23 Jun 2009 11:36:49 GMT
-XX:+*HeapDumpOnOutOfMemoryError** **is also very useful for post-mortems.*

On Tue, Jun 23, 2009 at 2:46 AM, Vassil Dichev <> wrote:

> > I added code that will dump memory information every 10 minutes.  Please
> put
> > the new code live.  If it barfs, please send me the output (privately is
> > better so we don't spam the list with a 10MB file)
> > I'm running an instance on my local box and will see if I can find memory
> > leaks.
> This is cool, but I'm afraid we might need some extra info from the
> JVM. I'm not sure you can change the command-line or environment you
> use to start the application in Stax, but this should display detailed
> information for the Sun JVM.
> MAVEN_OPTS=-verbose:gc -XX:+PrintGCDetails -XX:+PrintClassHistogram
> and for extra debugging, you can turn on the built in profiler with
> the following options:
> -Xrunhprof:heap=sites,cpu=samples,doe=y
> It will make the JVM run even slower, but could really pinpoint where
> the problem was.
> As for thread dumps, they're even more useful if you encounter the
> 100% CPU issue, but we need to send a signal to the JVM, which I'm not
> sure you can do at all in a managed stax environment. There are
> solutions to trigger it programmatically, but you need to include a
> native library, which is another restriction we might not be able to
> overcome.
> All in all, it would be much better if we can reproduce it locally,
> where we can play with the application. I assume you couldn't set
> MAVEN_OPTS last time there was a problem, since there was no feedback.
> Monitoring an app for memory problems in a restricted environment is
> notoriously hard.
> Vassil


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message