The ColdFusion Java Heap works perfect when JRockit Console window is open, but memory use skyrockets then crashes when JRockit Console is closed

Question

We have been having issues with our ColdFusion server and getting the JRE configured properly. In order to troubleshoot what was going on with this, we installed Oracle JRockit and switched over the jvm.config to try and find any memory leaks.

Once we installed JRockit our server was running better than ever. We kept the JRockit Program and Console open for several days and our memory usage stayed under 200mb. We finally closed the program on the server and immediately the memory usage problem returned.

Here is a screen shot of the Java Heap from FusionReactor to illustrate what is going on.

I could not post this directly here since I do not have enough reputation points yet: http://www.weblisters.com/icm/FusionReactorJavaHeap-JRockit-Console.png

Here are the main settings from our jvm.config file:

java.home=C:/Progra~2/Java/jrockit-jdk1.6.0_33-R28.2.4-4.1.0/jre  

java.args=-server -Xms1024m -Xmx1024m  -Xgc:parallel -Dsun.io.useCanonCaches=false -Dcoldfusion.rootDir={application.home}/ -XX:+HeapDumpOnOutOfMemoryError -Xmanagement:ssl=false,authenticate=false,autodiscovery=true

This error was thrown right after we closed the Jrockit console: Error: Not enough storage is available to process this command in tsStartJavaThread (src/jvm/threads/vmthread/lifecycle.c:1096).

Attempting to allocate 1G bytes There is insufficient native memory for the Java Runtime Environment to continue.

Does anyone know why garbage collection (GC) appears to work so much better with the JRockit Console window open and running? We can't leave it open as a permanent solution.

Answer 1

I thought that I would post an update to a resolution that ended up working for us. I am not sure exactly why the GC seemed to be running much better while using JRockit (specifically during the memory leak test), but we have found a setting for the JVM machine that seems to have enabled us to control the frequency the GC is called.

-Dsun.rmi.dgc.client.gcInterval=27000 -Dsun.rmi.dgc.server.gcInterval=27000

These two settings allow us to specifically call the GC as frequently or as infrequently as we want, and we needed to change it from the default setting. We also did update our entire java.args line based on a few great blog articles (linked at the bottom). Here is our updated java.args that has our server running like it should.

java.args= -server -DJINTEGRA_NATIVE_MODE -DJINTEGRA_PREFETCH_ENUMS -Xmx1024m -Xms1024m -XX:MaxPermSize=192m -XX:PermSize=192m  -XX:+UseParallelGC -Dsun.rmi.dgc.client.gcInterval=27000 -Dsun.rmi.dgc.server.gcInterval=27000 -Dcoldfusion.rootDir={application.home}/ -Djava.compiler=NONE -Xnoagent -Xdebug 

Blog articles:

Trunkful.com CF_GEMS How to Tune the JVM Part 1

Trunkful.com CF_GEMS How to Tune the JVM Part 2