On Jul 12, 2008, at 9:42 AM, Peter L. Berghold wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tim McConnell wrote:
-Xms256m -Xmx256m
Thanks for the pointer. I've implemented this suggestion thusly:
JPDA_OPTS="-Xdebug -Xms256m -Xmx256m
-
-Xrunjdwp:transport=$JPDA_TRANSPORT,address=
$JPDA_ADDRESS,server=y,suspend=$JPDA_SUSPEND"
Is there a point of diminishing returns on these values? I'm actually
running three separate web apps (websites) on the same server so I
want
to make sure they are not being starved for memory.
How big are your apps? Are you running out of heap memory or permgen
memory (assuming you're on a Sun VM). Are you deploying/undeploying
apps?
Also, are you debugging the server/your applications? If not, then
there's no reason to be running with JPDA.
If you're using the geronimo.sh/.bat script to start Geronimo. I'd:
export JAVA_OPTS="-Xmx512m -XX:MaxPermSize=128m"
./geronimo.sh run
JAVA_OPTS would alter both 'run' and 'jpda run'. So, works in either
scenario...
There are a couple of ways to monitor memory usage. One is to use the
Server Information portlet on the admin console e.g.:
http://localhost:8080/console/portal/Server/Information
This will only monitor server heap memory.
Alternatively, have the JVM dump memory usage statistics:
export JAVA_OPTS="-Xmx512m -XX:MaxPermSize=128m -verbose:gc -XX:
+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError"
Assuming you're running a Sun VM, this will dump detailed GC
statistics to STDOUT. The -XX:+HeapDumpOnOutOfMemoryError parm will
cause a heap dump to be generated if an OOM error occurs. This can be
used for post-mortem analysis by a number of tools.
--kevan
