Skip to main content

ConcurrentMarkSweep not running, only ParNew runs.

4 replies [Last post]
Joined: 2010-07-10

While doing load tests, I see my application show behaviour of a memory leak. It hits the heap 3 GB and after that GC seems to recover very little memory with every run, and it gets lesser and lesser with subsequent runs.
This is JDK 1.6 and and the app runs on Tomcat.

Here's relevant JVM args:

-Xms4g -Xmx4g -XX:ThreadStackSize=256 -Xmn512m -XX:SurvivorRatio=3 -XX:MaxTenuringThreshold=31 -XX:TargetSurvivorRatio=90 -XX:PermSize=256m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -XX:+HeapDumpOnOutOfMemoryError

Also, I notice that only ParNew runs, ConcurrentMarkSweep doesn't run. It only runs when I force it using JConsole.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-15

1) it is a bit confusing to diagnose a memory leak when running with CMS. This is because both young and old are collected at different times.
2) it is not possible to diagnose without a collection in old space. Young gen objects will be promoted and then if they die in old they will still be reported as using space
3) you have target survivor ratio set a 90 and suvivor ratio set to 3. This is pretty confusing.
4) The largest supported MaxTenuringThreshold is 18 (IIRC) even though there are 5 bits in the header used to support this parameter. That said, survivor ratio of 3 and tenuring threshold of 15 (default) are generally counter productive. I suspect that you are retaining objects in young that should be promoted. You need -XX:+PrintTenuringDistribution turned on to know for sure
5) Not having -XX:+PrintGCDetails make any meaningful analysis difficult
6) Depending on which 1.6 build you are using, you may not be sweeping perm space.
7) it is generally not a good idea to set -Xmn. In this case having new be far less than the normal 60/40 split of old to new is most likely not a good idea. You need GCDetails to know for sure
8) CMSInitiatingOccupancyFraction should only be set (generally lower) if CMS fragementation is a problem. Exposed by GC details showing CMS failures.

Kirk Pepperdine

Joined: 2004-01-07

Wow! Do you have a reason you use so many options, or have you copy&pasted from somewhere else?

What I do in such cases is to create a Heap-Dump using jconsole and use jhat to look which objects are kept alive and why.

- clemens

Joined: 2010-07-10

We had access to an person with expertise on JVM tuning, which we do not now. Thiese options were put in based on his findings.

Joined: 2004-01-07

1. Try without all those in-depth CMS options, those really should be enough:

-Xms4g -Xmx4g -XX:ThreadStackSize=256 -Xmn512m -XX:PermSize=256m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=70 -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -XX:+HeapDumpOnOutOfMemoryError

2. Does the app OOM, without CMS ever beeing triggered?

3. What dies jhat tell you? You can force a head-dump using jconsole, even when the app does not run out of memory.

- Clemens