High Eden Java Memory Usage/Garbage Collection

[TechHit]

Hi,

I am trying to make sure that my Coldfusion Server is optomised to the max and to find out what is normal limits.

Basically it looks like at times my servers can run slow but it is possible that this is caused by a very old bloated code base.

Jrun can sometimes have very high CPU usage so I purchased Fusion Reactor to see what is going on under the hood.

Here are my current Java settings (running v6u24):

java.args=-server -Xmx4096m -Xms4096m -XX:MaxPermSize=256m -XX:PermSize=256m -Dsun.rmi.dgc.client.gcInterval=600000 -Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.io.useCanonCaches=false -XX:+UseParallelGC -Xbatch ........

With regards Memory, the only memory that seems to be running a lot of Garbage Collection is the Eden Memory Space. It climbs to nearly 1.2GB in total just under every minute at which time it looks like GC kicks in and the usage drops to about 100MB.

Survivor memory grows to about 80-100MB over the space of 10 minutes but drops to 0 after the scheduled full GC runs. Old Gen memory fluctuates between 225MB and 350MB with small steps (~50MB) up or down when full GC runs every 10 minutes.

I had the heap set to 2GB initally in total giving about 600MB to the Eden Space. When I looked at the graphs from Fusion Reactor I could see that there was (minor) Garbage Collection about 2-3 times a minute when the memory usage maxed out the entire 600MB which seemed a high frequency to my untrained eye. I then upped the memory to 4GB in total (~1.2GB auto given to Eden space) to see the difference and saw that GC happened 1-2 times per minute.

Is it normal in Coldfusion that the Eden memory would grow so quickly and have garbage collection run so often? i.e do these graphs look normal?

Also should I somehow redistribute the memory available to give the Eden memory more since it seems to be where all the action is?

Any other advice for performance improvements would be much appreciated.

Note: These graphs are not from a period where jrun had high CPU.

Here are the graphs:

PS Eden Space Graph

PS Survivor Space Graph

PS Old Gen Graph

PS Perm Gen Graph

Heap Memory Graph

Heap/Non Heap Memory Graph

CPU Graph

Request Average Execution Time Graph

Request Activity Graph

Code Cache Graph

[carl type3]

Hi,

>Is it normal in Coldfusion that the Eden memory would grow so quickly and have garbage collection run so often?

Yes normal to garbage collect Eden often. That is a minor garbage collection.

>Also should I somehow redistribute the memory available to give the Eden memory more since it seems to be where all the action is?

Sometimes it is good to set Eden (Eden and its two Survivor Spaces combined make up New or Young Generation part of JVM heap) to a smaller size. I know your thinking - what make it less, but I want to make it bigger. Give less a try (sometimes less = more, bigger not = better) and monitor the situation. I like to use -Xmn switch, some sources say to use other method/s. Perhaps you could try java.args=-server -Xmx4096m -Xms4096m -Xmn172m etc. I better mention make a backup copy of jvm.config before applying changes. Having said that now you know how you can set the size to bigger if you want.

I think the JVM is perhaps making some poor decisions with sizing the heap. With Eden growing to 1Gb then being evacuated not many objects are surviving and therefore not being promoted to Old Generation. This ultimately means the object will need to be loaded again latter to Eden rather than being referenced in the Old generation part of the heap. Adds up to poor performance.

>Any other advice for performance improvements would be much appreciated.

You are using Parallel garbage collector. Perhaps you could enable that to run multi-threaded reducing the time duration of the garbage collections, jvm args ...-XX:+UseParallelGC -XX:ParallelGCThreads=N etc where N = CPU cores (eg quad core = 4).

HTH, Carl.

[Neo Rye]

In my environment I was having an issue with the ":+UseParallelGC" option, so I started using "+UseConcMarkSweepGC" with better luck. I think +UseConcMarkSweepGC has a higher CPU cost, but memory usage and GC seems to be better controlled with it. Might want to give it a spin and see how it goes.

I think that the graphs looking "normal" is going to be in the context of your application an environment. I tend to watch "Running Requests" to see long running requests or the "Longest Request / Slow Requests" log to look for application issues. If you refine some of the hogs, the rest of the app will run better. As long as my "Average Request Time" is around 125ms (for me) and I'm not running out of memory, I'm doing OK and would consider that "normal". If you already haven't done it, you might want to use the JDBC wrapper FR has to keep an eye on your queries too.

Here is my jvm :

java.args=-server -Xms6144m -Xmx6144m -Dsun.io.useCanonCaches=false -XX:PermSize=128m -XX:MaxPermSize=512m -Dsun.rmi.dgc.server.gcInterval=300000 -Dsun.rmi.dgc.client.gcInterval=300000 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Xbatch...

[margaret m griffith]

When you notice high Eden memory usage in your JVM, it’s directly tied to how Java Garbage Collection (GC) manages short-lived objects in the Young Generation. As a Java Architect, let me break this down for you in practical terms:

Why Eden Memory Usage is High

1. High Object Allocation Rate

   • Eden space is where all new objects are created. If your application is allocating objects too quickly (e.g., heavy loops, JSON/XML parsing, high request throughput), Eden fills up rapidly.

2. Insufficient Young Generation Size

   • If the Eden space is too small compared to your workload, minor GCs will happen more frequently.

3. Inefficient Garbage Collection Strategy

   • Depending on the GC algorithm (G1, Parallel, CMS, ZGC), the handling of Eden objects differs. Some collectors are more aggressive with promotion, while others try to reclaim Eden space faster.

How Java Garbage Collection Handles Eden

• When Eden fills up, a Minor GC is triggered.

• Live objects are moved (or copied) to Survivor spaces (S0/S1).

• If objects survive multiple cycles, they are promoted to the Old Generation.

• This process ensures short-lived objects die quickly without cluttering Old Gen.

Monitoring High Eden Usage in Docker

Inside a Docker container, memory visibility can be tricky because the JVM might not be container-aware unless you’re on newer JDKs (Java 11+). To monitor GC effectively:

1. Enable GC Logging

   -Xlog:gc*:file=/var/log/gc.log:time,uptime,level,tags

   This gives you detailed GC events, including Eden allocations.

2. Use JMX + Monitoring Tools
   Expose JMX metrics and integrate with Prometheus + Grafana, or tools like VisualVM, JConsole, or Eclipse MAT.

3. Tune JVM Memory Settings
   Example flags for Docker:

   -XX:+UseG1GC -XX:MaxRAMPercentage=75.0 -XX:+UnlockExperimentalVMOptions -XX:+UseContainerSupport

   These ensure the JVM respects container memory limits and optimizes Eden usage.

Best Practices to Reduce High Eden Usage

• Optimize code to reduce short-lived object creation (e.g., use object pools, avoid unnecessary string concatenations).

• Right-size the Young Generation using -Xmn, -XX:NewRatio, or let G1 handle it dynamically.

• Use profilers (YourKit, JFR, VisualVM) to track memory churn.

• Avoid over-allocation when container memory is small—otherwise frequent GC will degrade performance.
  
  

In short: High Eden memory usage usually means your application is creating many temporary objects.   is designed to clean Eden efficiently via Minor GCs, but tuning GC strategy and JVM memory parameters in a Docker environment is critical to avoid excessive GC overhead and performance bottlenecks.

Also read, https://blog.gceasy.io/what-is-java-garbage-collection/

[Charlie Arehart]

Hmm. This 2011 post makes no mention of docker (since it didn't exist then). If you're going to search the web for posts mentioning high eden space use, to drop in this text, please consider revising your text at least a bit to suit the post--otherwise it reads like a cut/paste promotional piece, if not like a bad AI answer.

That said, I certainly appreciate gceasy and all their related tools, as well as the knowledge they share on their site/s. And Carl's 2011 reply was spot on: we're blessed he's still here helping folks nearly 15 years later. So is FusionReactor, advancing as always.

As for neo rye's helpful answer, we should note that +UseConcMarkSweepGC was deprecated in Java 9 and finally removed in Java 15, so can't be used with cf2023 (which runs on Java 17) and so on. And more could be said about the problem the OP faced, but they never replied and may well have moved on long ago. 

Anyway, I thought some perspective might be warranted if others saw this message of yours popping up as a recent reply in the web ui of these cf forums.