Pete Freitag Pete Freitag

ColdFusion Garbage Collection

Updated on November 14, 2023
By Pete Freitag
coldfusion

Now that you have had a chance to read my outline of garbage collection tuning in java. You should be asking yourself how does this relate to my ColdFusion server. Or maybe you just wondered what Garbage Collection has to do with ColdFusion Servers.

So I'll start with a really quick overview of what garbage collection (GC) is. In Java your variables are represented as objects on the heap (the heap is the chunk of memory you allocate to the JVM), the objects are considered to be either alive (in use) or dead (out of scope, no references point to it). For instance when you have a request variable, it is out of scope at the end of your http request (there is no way to access that variable again). So the Java Virtual Machine (the JVM) needs some way of freeing the memory that dead objects are taking up, this process is called garbage collection.

The first thing you might notice after reading the garbage collection outline is that ColdFusion MX 6.1 is using the throughput collector, or the parallel young generation collector (-XX:+UseParallelGC) by default. If your ColdFusion server only has one CPU you may get better performance by using the default collector. If you have hyperthreading enabled CPU's you may be ok. If your server has multiple CPU's you may try tuning the number of threads that the parallel collector is using with -XX:ParallelGCThreads=n.

If you have 4 CPU's with lots of RAM you might want to try adding -XX:+AggressiveHeap to your JVM startup options. You might also want to try this if you have 2 CPU's with hyperthreading enabled.

It may be a good idea to increase your -XX:MaxPermSize=n if you have a lot of CFM files. Since each file is a class, you are adding a lot of class and method info to the perm generation.

Another thing you can try tuning is the sizes of the young and tenured generations. You can do this with the -XX:NewRatio option. If you have a lot of cached, or persistent variables you will want to have a bigger tenured generation. But if your doing a lot of dynamic execution then you may be better off increasing your young generation.

Tuning is always about tradeoffs, and the specifics of your application, and your hardware.



cf gc jvm java performance

ColdFusion Garbage Collection was first published on June 03, 2004.

If you like reading about cf, gc, jvm, java, or performance then you might also like:

Fixinator

The Fixinator Code Security Scanner for ColdFusion & CFML is an easy to use security tool that every CF developer can use. It can also easily integrate into CI for automatic scanning on every commit.


Try Fixinator

CFBreak
The weekly newsletter for the CFML Community


Comments

More info about CF and GC here: http://www.sumoc.com/blog/index.cfm?mode=entry&entry=CDCDBF8B-5004-2066-B7460CDEAB79328F
by Pete Freitag on 06/08/2004 at 5:02:24 PM UTC
thanks for this!
I've been meaning to learn more about garbage collection in ColdFusion and I intend to start from the basics.
by kathy on 10/26/2008 at 7:35:27 PM UTC
I have just posted a new blog entry which shows how you can do programmatic garbage collection if your memory gets below a certain threshold.. Hope it helps:-
http://www.beetrootstreet.com/blog/index.cfm/2009/6/25/Clearing-ColdFusion-memory-using-garbage-collection-when-memory-gets-low
by Coldfusion Developer on 06/25/2009 at 8:00:50 AM UTC
I am wondering if this relates to an issue found during development of a batch process.
Encapsulated in CFC's, the batch process executes a bunch of queries against a mySQL database schema, and outputs the results of minor computations into a text file. The process takes in excess of 15 minutes to run.
What I find is that after about 8 - 10 mins, the process starts to slow down, and CPU utilisation on the server takes a stepwize jump to 100 percent with little gaps. The gaps get further apart until finally the server grinds to a halt, and my only option is to restart the Cold Fusion service - if I can open up the services dialog that is. I have tried adding in calls to java.Thread.sleep(n) and while this has extended the time before it croaks, the result is pretty much the same.
I assume this is all caused by depletion of some scarce resource.

So, clutching at straws, I am wondering if attempts to tune the JVM GC will alleviate or cure the problem.

I am wondering if someone can help out with a pointer to a careful and evidence driven methodology of approach to performing such tuning.

Cheers
....
by Bryn Parrott on 11/19/2010 at 12:18:22 AM UTC
I'm running a mixed environment currently. Some CF 8 Enterprise servers and some CF 9 Enterprise servers. (we are trying to migrate all applications to CF9 but there are still a few hold outs). At any rate. My question is, does the -XX:+AggressiveHeap setting still work with CF 8 & 9 AND how would it react with mutiple instances of CF on a Server?

Thanks.
by Robert Owen on 01/20/2012 at 10:42:52 AM UTC