Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of erik.engbrecht@gmail.com
 designates 209.85.219.223 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=ImBaIyWeHndzj4bwW9bFJNnlkX+GfRvbjYdGq2gHkNv1IOW4EEoPVaCE7U3O7FCLDx
         2wIEe6E1da9RrGXZ+bmPbQXzNY0lYb2tHb9y+myHxmWUUwFr5SlsuDZwYeaTmAy4ZfLh
         cm89bHDiSfnZellMtwUvk20uGsZSbihdObdxE=
MIME-Version: 1.0
In-Reply-To: <c7fc82820906222346q1c800a5cn17e1a8cc3ca7c92c@mail.gmail.com>
References: <fa2d9f450906212359h1e618a10l49c02f9a10e158fb@mail.gmail.com>
	 <cdbebedf0906220829m54629c2egd6709641948a4186@mail.gmail.com>
	 <fa2d9f450906221041qc8573c0g456efe79b6c0de3b@mail.gmail.com>
	 <cdbebedf0906221403n7b52ce7dy3e006b6554e43ee0@mail.gmail.com>
	 <c7fc82820906222346q1c800a5cn17e1a8cc3ca7c92c@mail.gmail.com>
Date: Tue, 23 Jun 2009 07:36:49 -0400
Message-ID: <9d8b82ea0906230436l1598b9f3l5b6738c251dc8d2b@mail.gmail.com>
Subject: Re: Memory usage -> stability probs?
From: Erik Engbrecht <erik.engbrecht@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0016368e2f4e0488f6046d026818

--0016368e2f4e0488f6046d026818
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

-XX:+*HeapDumpOnOutOfMemoryError** **is also very useful for post-mortems.*

On Tue, Jun 23, 2009 at 2:46 AM, Vassil Dichev <vdichev@apache.org> 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
>


-- 
http://erikengbrecht.blogspot.com/

--0016368e2f4e0488f6046d026818--