Avoiding 1 long CMS with a big heap

[Jon Masamitsu]

Matt,

What jdk release are you using?

Can you send the GC log for a few of the young generation collections
before the initial mark (the very long pause of ~ 4secs)?  For a few young
generation collections after the end of the CMS cycle may be
interesting too.

Does the long pause occur with every initial mark (CMS-initial-mark)
or just the first one?

What type of  platform are you running on?

Why are you using CMSIncrementalMode?

You seem to have decided to promote (copy to the tenured
generation) everything that survives a young gen collection
(small MaxTenuringThreshold, small survivor spaces).
Is that to minimize the young gen collection pauses?

Jon


On 04/14/10 04:28, Matt Khan wrote:
> Hi
>
> I have been experimenting with larger heap sizes to see if I can reduce 
> the frequency of my pauses, the switches I have used are;
>
> -Xms16192m 
> -Xmx16192m 
> -Xmn16000m 
> -XX:+UseCompressedOops 
> -XX:+UseConcMarkSweepGC 
> -XX:+CMSIncrementalMode 
> -XX:+CMSIncrementalPacing 
> -XX:+UseParNewGC 
> -XX:MaxTenuringThreshold=1 
> -XX:+PrintTenuringDistribution 
> -XX:SurvivorRatio=1022 
> -XX:TargetSurvivorRatio=90 
> -XX:+DisableExplicitGC 
> -XX:+PrintGCDetails 
> -XX:+PrintGCDateStamps 
> -XX:+PrintGCApplicationStoppedTime 
> -XX:+PrintGCApplicationConcurrentTime
>
> This works quite well in that our average pause time is ~4ms every 30s or 
> so (albeit in the range 5-60s but most commonly about every 30s).
>
> There is one wrinkle and that is an initial, v long CMS pause. It happens 
> about ~40mins after start
>
> 2010-04-13T23:05:29.072+0000: 3342.854: [GC [1 CMS-initial-mark: 
> 12018K(196608K)] 7811496K(16564608K), 4.2147116 secs] [Times: user=4.15 
> sys=0.06, real=4.22 secs] 
> Total time for which application threads were stopped: 4.2243800 seconds
> 2010-04-13T23:05:33.288+0000: 3347.070: [CMS-concurrent-mark-start]
> Application time: 0.0021391 seconds
> Total time for which application threads were stopped: 0.0046091 seconds
> 2010-04-13T23:05:33.343+0000: 3347.125: [CMS-concurrent-mark: 0.048/0.056 
> secs] [Times: user=0.35 sys=0.15, real=0.06 secs] 
> 2010-04-13T23:05:33.344+0000: 3347.126: [CMS-concurrent-preclean-start]
> 2010-04-13T23:05:33.347+0000: 3347.128: [CMS-concurrent-preclean: 
> 0.003/0.003 secs] [Times: user=0.01 sys=0.01, real=0.00 secs] 
> 2010-04-13T23:05:33.347+0000: 3347.129: 
> [CMS-concurrent-abortable-preclean-start]
>  CMS: abort preclean due to time 2010-04-13T23:05:38.456+0000: 3352.238: 
> [CMS-concurrent-abortable-preclean: 0.573/5.109 secs] [Times: user=0.94 
> sys=0.24, real=5.11 secs] 
> Application time: 4.1574245 seconds
> 2010-04-13T23:05:38.461+0000: 3352.243: [GC[YG occupancy: 7824966 K 
> (16368000 K)]3352.243: [Rescan (parallel) , 4.2295340 secs]3356.473: [weak 
> refs processing, 0.0000422 secs] [1 CMS-remark: 12018K(196608K)] 
> 7836984K(16564608K), 4.2298963 secs] [Times: user=36.56 sys=1.65, 
> real=4.23 secs] 
> Total time for which application threads were stopped: 4.2351364 seconds
> 2010-04-13T23:05:42.692+0000: 3356.473: [CMS-concurrent-sweep-start]
> Application time: 0.0003415 seconds
>
> What I would like to understand is why there is such a long pause when the 
> tenured is nowhere near full (~12m of 192m occupied)? and hence whether 
> this can be avoided?
>
> Cheers
> Matt
>
> Matt Khan
> --------------------------------------------------
> GFFX Auto Trading
> Deutsche Bank, London
>
>
>
> ---
>
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
>
> Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
> _______________________________________________
> 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: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20100414/8a77c03a/attachment.html