On Aug 18, 2009, at 2:24 PM, Russell Collins wrote:
I am having an issue with Geronimo and memory. First, this could be
a configuration issue or a memory leak. Here is what happens.
· When we build java objects, we deploy to the Geronimo
application server.
· We then run Junit tests to test the remote interface and
bring back data objects
· Most of the time, this works without a hitch. However,
after a while (say a good week or so) everything will break and say
that we are out of memory (perm size)
I know that one on the actions that can be taken is to update the
perm size. First question is to how to do this correctly for
Geronimo? Second, what is the ideal perm size (if there is one) for
Geronimo.
What version of Geronimo?
I assume by "deploy" you mean deploy/undeploy?
Typically, there are two causes of PermGen OOME's:
1) Your application(s) are too large, and you need to increase your -
XX:MaxPermSize= setting
2) If you are deploying/undeploying applications, and your PermGen
utilization keeps increasing, then you have a ClassLoader memory leak.
Bumping your MaxPermSize setting will postpone your OOME, but it's
only a matter of time.
2) is a bug -- either in Geronimo, your application, or libraries
included with your application.
The best way I've found to diagnose is to set "-XX:-
HeapDumpOnOutOfMemoryError". This will cause the JVM to generate a
head dump when it encounters an OutOfMemoryError. This will create a
java_pid<pid>.hprof file in the current directory. There are some
additional controls (e.g. you can configure a destination directory
for the hprof file, but I just let it go to the working directory...).
Using the .hprof file, it's then possible to perform post-mortem
analysis. Best tools that I've found for this are either YourKit or
Eclipse Memory Analyzer (MAT).
If you have a test case that you can share, I'll take a look at it. Or
if you generate a heap dump, I can help look at that...
--kevan
