Identifying concurrent mode failures caused by fragmentation

Jon Bright jon at siliconcircus.com
Mon Oct 31 06:06:54 PDT 2011


Hi,

We have an application running with a 6GB heap (complete parameters 
below).  Mostly it has a fairly low turnover of memory use, but on 
occasion, it will come under some pressure as it reloads a large 
in-memory data set from a database.

Sometimes in this situation, we'll see a concurrent mode failure. 
Here's one failure:

20021.464: [GC 20021.465: [ParNew: 13093K->3939K(76672K), 0.0569240 
secs]20021.522: [CMS20023.747: [CMS-concurrent-mark: 11.403/29.029 secs] 
[Times: user=41.11 sys=1.03, real=29.03 secs]
  (concurrent mode failure): 3873922K->2801744K(6206272K), 30.7900180 
secs] 3886215K->2801744K(6282944K), [CMS Perm : 
142884K->142834K(524288K)] icms_dc=33 , 30.8473830 secs] [Times: 
user=30.26 sys=0.71, real=30.85 secs]
Total time for which application threads were stopped: 30.8484460 seconds

(I've attached a lengthier log including the previous and subsequent CMS 
collection.)

Am I correct in thinking that this failure can basically only be caused 
by fragmentation?  Both young and old seem to have plenty of space. 
There doesn't seem to be any sign that the tenured generation would run 
out of space before CMS completes.  Fragmentation is the only remaining 
cause that occurs to me.

We're running with 1.6.0_11, although this will be upgraded to 1.6.0_26 
tomorrow.  I realise our current version is ancient - I'm not really 
looking for help on the problem itself, just for advice on whether the 
log line above indicates fragmentation.

Thanks

Jon Bright



The parameters we have set are:

-server
-Xmx6144M
-Xms6144M
-XX:MaxPermSize=512m
-XX:PermSize=512m
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing
-XX:SoftRefLRUPolicyMSPerMB=3
-XX:CMSIncrementalSafetyFactor=30
-XX:+PrintGCDetails
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCApplicationConcurrentTime
-XX:+PrintGCTimeStamps
-Xloggc:/home/tbmx/log/gc_`date +%Y%m%d%H%M`.log

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gc_20111031_jonbright.log
Url: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20111031/474c9fe8/gc_20111031_jonbright-0001.log 


More information about the hotspot-gc-use mailing list