High Eden Java Memory Usage/Garbage Collection
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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...

