Home/ Questions/Q 8495461
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-10T23:34:51+00:00

We have been having issues with our ColdFusion server and getting the JRE configured

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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

    • 0