On Mar 6, 2008, at 10:37 AM, Jim Foster wrote:
Hi Peter,
Thank you for this info!
I took your suggestion and brought myself up to speed on PermGen,
and a good
bit of all things related to Java.lang.OutOfMemoryError.
All I can say is that there's certainly a lot more to fine-tuning the
classloading going on behind the scenes than one would first imagine.
This brings up another question: How do you folks manage this?
What tools would you recommend that I add to my toolbox so that I
can really
understand what's really going on beneath the covers?
As I mentioned in my earlier post, this project I am involved with
will be
weaving together several applications to be deployed on top of
Geronimo, so
sooner or later, fine-tuning performance issues will become a reality.
I'd like to get a handle on such things as early in the development
cycle as
possible.
Hi Jim,
There are a lot of knobs and switches. However, you can cause as much
harm as good trying to fine tune their settings. My advice to you is
to keep things as simple as possible until you know you have a problem.
The JVM can print GC statistics to STDOUT. Often I find this
sufficient for getting a broad overview of what's going on. You can
also configure the JVM to create a heapdump on OOME conditions. If you
have a memory leak, you can then analyze the heapdump using a variety
of tools (I like YourKit). There are a number of tools which can also
perform further analysis on runtime data (memory allocations, method
execution, etc).
Something like the following should work (set max heap and max perm
to suit your environment):
-Xmx512m -XX:MaxPermSize=128m -verbose:gc -XX:+PrintGCDetails -XX:
+HeapDumpOnOutOfMemoryError
--kevan
