Identifying concurrent mode failures caused by fragmentation

[Jon Masamitsu]

Jon,

I noticed that you are using the incremental mode of
CMS.  May I ask why you chose to turn that on?

Jon

On 10/31/2011 7:43 PM, Jon Masamitsu wrote:
> Jon,
>
> I haven't looked at the longer log but in general I've found the
> information in the GC logs inadequate to figure out if the
> problem is fragmentation.  But more important, there has
> been some good work in recent versions of hotspot so that
> we're more successful at combating fragmentation.  Try
> the latest release and see if it helps (u26 should be good
> enough).
>
> Jon
>
> On 10/31/11 06:06, Jon Bright wrote:
>> 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
>>
>>
>>
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111031/40c89aab/attachment.htm>
-------------- next part --------------
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use