Exit
  • Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
  • 한국 커뮤니티
0

High Eden Java Memory Usage/Garbage Collection

New Here ,
Sep 04, 2011 Sep 04, 2011

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

http://img833.imageshack.us/img833/7002/psedenspacegraph.png

PS Survivor Space Graph

http://img69.imageshack.us/img69/3241/pssurvivorspacegraph.png

PS Old Gen Graph

http://img689.imageshack.us/img689/8093/psoldgengraph.png

PS Perm Gen Graph

http://img6.imageshack.us/img6/3291/pspermgengraph.png

Heap Memory Graph

http://img692.imageshack.us/img692/2348/heapmemorygraph.png

Heap/Non Heap Memory Graph

http://img196.imageshack.us/img196/594/heapnonheapmemorygraph.png

CPU Graph

http://img28.imageshack.us/img28/8781/cpugraph.png

Request Average Execution Time Graph

http://img33.imageshack.us/img33/6573/requestaverageexecution.png

Request Activity Graph

http://img845.imageshack.us/img845/5065/requestactivitygraph.png

Code Cache Graph

http://img6.imageshack.us/img6/6620/codecachegraph.png

TOPICS
Monitoring
11.0K
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guide ,
Sep 04, 2011 Sep 04, 2011

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.

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Sep 15, 2011 Sep 15, 2011
LATEST

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...

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources