G1 is bad for me

[Andrei Pozolotin]

these are CMS settings and log sample, for same reference load

++++++++++++++++++++++++++++++++++++++++++++++++

wrapper.java.additional.100=-server

# do GC logging
wrapper.java.additional.110=-verbose:gc
wrapper.java.additional.111=-Xloggc:./logs/gc.log
wrapper.java.additional.112=-XX:+PrintGCDetails
wrapper.java.additional.113=-XX:+PrintGCTimeStamps

# Heap Total = PermGen + NewGen + OldGen;
wrapper.java.additional.120=-Xms3700m
wrapper.java.additional.121=-Xmx3700m

# PermGen;
wrapper.java.additional.130=-XX:PermSize=50m
wrapper.java.additional.131=-XX:MaxPermSize=50m

# NewGen; Parallel collector;
wrapper.java.additional.140=-XX:NewSize=1800m
wrapper.java.additional.141=-XX:MaxNewSize=1800m
wrapper.java.additional.142=-XX:-UseAdaptiveSizePolicy
wrapper.java.additional.143=-XX:SurvivorRatio=1
wrapper.java.additional.144=-XX:TargetSurvivorRatio=90
wrapper.java.additional.145=-XX:MaxTenuringThreshold=2
wrapper.java.additional.146=-XX:+UseParNewGC
wrapper.java.additional.147=-XX:-UseParallelGC
wrapper.java.additional.148=-XX:ParallelGCThreads=4

# OldGen; Incremental CMS collector;
wrapper.java.additional.170=-XX:-UseParallelOldGC
wrapper.java.additional.171=-XX:+UseConcMarkSweepGC
wrapper.java.additional.172=-XX:+UseCMSInitiatingOccupancyOnly
wrapper.java.additional.173=-XX:CMSInitiatingOccupancyFraction=24
wrapper.java.additional.175=-XX:+CMSParallelRemarkEnabled
wrapper.java.additional.176=-XX:+CMSScavengeBeforeRemark
wrapper.java.additional.179=-XX:CMSWaitDuration=60000
wrapper.java.additional.181=-XX:ParallelCMSThreads=1
wrapper.java.additional.182=-XX:PrintCMSStatistics=0

++++++++++++++++++++++++++++++++++++++++++++++++

1426.274: [GC 1426.274: [ParNew: 615748K->1899K(1228800K), 0.0369160
secs] 1048474K->434948K(3174400K), 0.0370710 secs] [Times: user=0.10
sys=0.00, real=0.04 secs]
1440.019: [GC 1440.019: [ParNew: 616299K->1474K(1228800K), 0.0353210
secs] 1049348K->434647K(3174400K), 0.0354860 secs] [Times: user=0.09
sys=0.00, real=0.03 secs]
1452.544: [GC 1452.544: [ParNew: 615874K->1506K(1228800K), 0.0349110
secs] 1049047K->434841K(3174400K), 0.0350570 secs] [Times: user=0.09
sys=0.00, real=0.03 secs]
1467.298: [GC 1467.298: [ParNew: 615906K->1916K(1228800K), 0.0292920
secs] 1049241K->435408K(3174400K), 0.0295150 secs] [Times: user=0.12
sys=0.00, real=0.03 secs]
1480.940: [GC 1480.940: [ParNew: 616316K->1629K(1228800K), 0.0284240
secs] 1049808K->435324K(3174400K), 0.0285660 secs] [Times: user=0.11
sys=0.00, real=0.02 secs]
1490.471: [GC 1490.472: [ParNew: 616029K->2056K(1228800K), 0.0306450
secs] 1049724K->435967K(3174400K), 0.0308110 secs] [Times: user=0.12
sys=0.00, real=0.03 secs]
1503.550: [GC 1503.550: [ParNew: 616456K->2198K(1228800K), 0.0323910
secs] 1050367K->436251K(3174400K), 0.0325430 secs] [Times: user=0.12
sys=0.00, real=0.03 secs]
1514.911: [GC 1514.911: [ParNew: 616598K->1687K(1228800K), 0.0315140
secs] 1050651K->436052K(3174400K), 0.0316790 secs] [Times: user=0.12
sys=0.00, real=0.03 secs]
1524.320: [GC 1524.320: [ParNew: 616087K->1773K(1228800K), 0.0300510
secs] 1050452K->436382K(3174400K), 0.0302330 secs] [Times: user=0.12
sys=0.00, real=0.03 secs]
1529.386: [GC 1529.386: [ParNew: 616173K->1671K(1228800K), 0.0297700
secs] 1050782K->436438K(3174400K), 0.0299210 secs] [Times: user=0.11
sys=0.00, real=0.03 secs]

++++++++++++++++++++++++++++++++++++++++++++++++

-------- Original Message  --------
Subject: Re: G1 is bad for me
From: Chi Ho Kwok <chkwok at digibites.nl>
To: hotspot-gc-use <hotspot-gc-use at openjdk.java.net>
Date: Fri 19 Feb 2010 08:59:53 AM CST
> Hi all,
>
> A large part of our CPU load is caused by GC, so I'm always interested
> in new techniques, but the last time I tried G1 (6u14?), the jvm
> rapidly crashed after startup under load. Is the recommendation to
> switch to/wait for JDK7 releases for G1, or is G1 on 6u18 (or later?)
> any good for production usage? I'd assume there will be more updates
> for JDK6 as JDK7 got extended to up to 10 milestones.
>
> CMS with a 32G heap which changes rapidly (~10%/min replaced) is
> manageable, but we're "losing" 20% capacity because the threshold has
> to be so low, anything higher than 80% causes new gen promotions to
> fail during CMS and the app to stop for half a minute. Processing
> capacity is also reduced by half during a CMS run because the amount
> of threads has to be high (=6 at the moment) to make it hurry up, or
> it'll mean either setting the threshold even lower or risk promotion
> failures :(
>
> Chi Ho Kwok
>
> On Thu, Feb 18, 2010 at 6:37 PM, Y. Srinivas Ramakrishna
> <Y.S.Ramakrishna at sun.com <mailto:Y.S.Ramakrishna at sun.com>> wrote:
>
>     Hi Andrei -- please use the latest hs17 JVM which you can get from
>     JDK 7. There have been
>     many improvements (and bug fixes) since the 6u18/hs16 that you are
>     using below.
>     Most importantly, please add -XX:-ReduceInitialCardMarks to work
>     around a regression
>     introduced in 6u18/hs16, as described in the 6u18 release notes.
>     As re optimal settings (these may be quite different from shapes
>     that helped with CMS
>     for example), i'll let others w/more (tuning and other) experience
>     w/G1 comment.
>
>     -- ramki
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/20100219/3d31e3ac/attachment.html