Databases
StackOverflow2013
Postsdbo
POJava ConcurrentMarkSweep garbage collector not happening
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POJava ConcurrentMarkSweep garbage collector not happening
    primarykey
    data
    text
    <p>Environment Details: OS: Linux RedHat Java: JRE 6 Update 21</p> <p>I am using following GC setting for my app.</p> <pre><code>-server -d64 -Xms8192m -Xmx8192m -javaagent:lib/instrum.jar -XX\:MaxPermSize=256m -XX\:+UseParNewGC -X\:+ParallelRefProcEnabled -XX\:+UseConcMarkSweepGC -XX\:MaxGCPauseMillis=250 -XX\:+CMSIncrementalMode -XX\:+CMSIncrementalPacing -XX\:+CMSParallelRemarkEnabled -verbose\:gc -Xloggc\:/tmp/my-gc.log -XX\:DisableExplicitGC -XX\:+PrintGCTimeStamps -XX\:+PrintGCDetails -XX\:+UseCompressedOops </code></pre> <p>With there setting, there is single Full GC at the begining of application</p> <pre><code>2.946: [Full GC 2.946: [CMS: 0K-&gt;7394K(8111744K), 0.1364080 secs] 38550K-&gt;7394K(8360960K), [CMS Perm : 21247K-&gt;21216K(21248K)], 0.1365530 secs] [Times: user=0.10 sys=0.04, real=0.14 secs] </code></pre> <p>Which is followed by a 4-5 successful of CMS collections, But after this there is <strong>no trace of CMS</strong> in logs, there are entries on only minor collections.</p> <pre><code>379022.293: [GC 379022.293: [ParNew: 228000K-&gt;4959K(249216K), 0.0152000 secs] 7067945K-&gt;6845720K(8360960K) icms_dc=0 , 0.0153940 secs] </code></pre> <p>The heap is growing continuously and it has reached 7GB. We have to restart the application as we can not afford OOM or any kind of breakdown in production system.</p> <p>I am not able to understand as to why CMS collector has stopped cleaning. Any clues/suggestions are welcome. Thanks in Advance.</p> <p>====================================================================================== Updated 23rd Jan.</p> <p>Thanks everyone for the responses till now. I have setup the application in test environment and tested the app with following set of JVM options:</p> <p>Option #1</p> <pre><code>-server -d64 -Xms8192m -Xmx8192m -javaagent\:instrum.jar -XX\:MaxPermSize\=256m -XX\:+UseParNewGC -XX\:+UseConcMarkSweepGC -verbose\:gc -Xloggc\:my-gc.log -XX\:+PrintGCTimeStamps -XX\:+PrintGCDetails </code></pre> <p>Option #2</p> <pre><code>-server -d64 -Xms8192m -Xmx8192m -javaagent\:instrum.jar -XX\:MaxPermSize\=256m -XX\:+UseParNewGC -XX\:+UseConcMarkSweepGC -verbose\:gc -Xloggc\:my-gc.log -XX\:+DisableExplicitGC -XX\:+PrintGCTimeStamps -XX\:+PrintGCDetails </code></pre> <p>I ran the test with both settings for 2 days in parallel. These are my observations:</p> <p>Option #1 The heap memory is stable but there are 90 ConcurrentMarkSweep collections and JVM spent 24 minutes. That’s too high. And I see following lines in GC logs and the pattern continues every one hour...</p> <pre><code>318995.941: [GC 318995.941: [ParNew: 230230K-&gt;8627K(249216K), 0.0107540 secs] 5687617K-&gt;5466913K(8360960K), 0.0109030 secs] [Times: user=0.11 sys=0.00, real=0.01 secs] 319050.363: [GC 319050.363: [ParNew: 230195K-&gt;9076K(249216K), 0.0118420 secs] 5688481K-&gt;5468316K(8360960K), 0.0120470 secs] [Times: user=0.12 sys=0.01, real=0.01 secs] 319134.118: [GC 319134.118: [ParNew: 230644K-&gt;8503K(249216K), 0.0105910 secs] 5689884K-&gt;5468704K(8360960K), 0.0107430 secs] [Times: user=0.11 sys=0.00, real=0.01 secs] 319159.250: [Full GC (System) 319159.250: [CMS: 5460200K-&gt;5412132K(8111744K), 19.1981050 secs] 5497326K-&gt;5412132K(8360960K), [CMS Perm : 72243K-&gt;72239K(120136K)], 19.1983210 secs] [Times: user=19.14 sys=0.06, real=19.19 secs] </code></pre> <p>I don’t see the concurrent mark and sweep logs. Does this mean CMS switched to throughput collector? If so why?</p> <p>Option #2:</p> <p>Since I see the Full GC (System) logs, I thought of adding -XX\:+DisableExplicitGC. But with that option the collection is not happening and the current heap size is 7.5G. What I am wondering is why CMS is doing the Full GC instead of concurrent collection.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USShiva
    1. USShiva
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POJava ConcurrentMarkSweep garbage collector not happening
      1. USSimonC
      1. VTFavorite
    2. VO
      singulars
      1. POJava ConcurrentMarkSweep garbage collector not happening
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POJava ConcurrentMarkSweep garbage collector not happening
      1. USVirtualVoid
      1. VTFavorite
    1. COare you running on a machine with a single core? if not, get rid of the incremental mode switches. This mode is pretty much completely obsolete these days. btw, it seems strange to say you can't afford an OoM in production but you can afford to restart the entire app. Do you see the same behaviour in your test environment?
      singulars
      1. POJava ConcurrentMarkSweep garbage collector not happening
      1. USMatt
    2. COapplication is running on multicore. Yes we can restart in noo-working hours but if production breakdowns in working hours its a huge problem...I have not seen this in test possibly because dont have enough load. I am trying to produce this is test now.
      singulars
      1. POJava ConcurrentMarkSweep garbage collector not happening
      1. USShiva
    3. COit sounds like your test strategy is inadequate tbh as you are running with non standard GC params that have never been subject to real stress
      singulars
      1. POJava ConcurrentMarkSweep garbage collector not happening
      1. USMatt
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload