frequent CMS collections/ CPU spike/ Hotspot JRE1.4.2_17/
vasu ts
vasu_t_s at hotmail.com
Mon Apr 20 20:18:18 PDT 2009
Thanks for the reply.
In our application, we generate lots of objects (xml marshalling and unmarshalling) which are never re-used. So we thought increasing the young gen would give enough time for the objects to die young.
Also, in the native logs seems like all the young gen is being filled up and is being collected. Does this mean the young gen should be allocated more space? ( this will mean the total heap size might have to increase also).
9168.037: [GC 9168.038: [ParNew: 504044K->0K(508096K), 0.1534303 secs] 669773K->196481K(782528K), 0.1547104 secs]
9168.356: [CMS-concurrent-sweep: 2.269/2.562 secs]
9168.356: [CMS-concurrent-reset-start]
9168.766: [CMS-concurrent-reset: 0.409/0.409 secs]
9170.798: [GC [1 CMS-initial-mark: 193751K(274432K)] 466502K(782528K), 2.8434545 secs]
9173.644: [CMS-concurrent-mark-start]
9176.626: [GC 9176.627: [ParNew: 504111K->0K(508096K), 0.1026683 secs] 697862K->214832K(782528K), 0.1035612 secs]
9177.017: [CMS-concurrent-mark: 3.133/3.373 secs]
9177.017: [CMS-concurrent-preclean-start]
9177.377: [CMS-concurrent-preclean: 0.319/0.359 secs]
9177.383: [GC9177.385: [Rescan (parallel) , 0.2564013 secs]9177.641: [weak refs processing, 0.0331580 secs] [1 CMS-remark: 214832K(274432K)] 282063K(782528K), 0.2928263 secs]
9177.679: [CMS-concurrent-sweep-start]
9178.515: [CMS-concurrent-sweep: 0.835/0.836 secs]
9178.516: [CMS-concurrent-reset-start]
9178.623: [CMS-concurrent-reset: 0.107/0.107 secs]
Will try out your suggestions -XX:MaxTenuringThreshold=15 -XX:SurvivorRatio=6 or 8.
vasu..
> Date: Mon, 20 Apr 2009 19:46:08 -0700
> From: Jon.Masamitsu at Sun.COM
> Subject: Re: frequent CMS collections/ CPU spike/ Hotspot JRE1.4.2_17/
> To: vasu_t_s at hotmail.com
> CC: hotspot-gc-use at openjdk.java.net
>
> With a total heap of 768m and a young gen pf 500m you
> might not have enough room in the tenured (old) gen.
> That is, the amount of free space left in the tenured gen
> may be so small that CMS thinks it need to start
> a collection immediately. Try a larger total heap
> or a smaller yount gen. I see that you're turning on
>
> -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=128
>
> so everything that survives a young gen is being
> promoted to the tenured gen. Those values reduce
> the CMS pause times but also fill up the tenured
> generation faster. If you don't have a specific reason
> to use those values, 15 for the tenuring threshold and
> 6 or 8 for the survivor ratio may serve you better.
>
>
>
>
> vasu ts wrote On 04/20/09 16:50,:
>
> > Hi all,
> >
> > We have an application which is deployed on IBM websphere 5.1/Solaris
> > 5.9/Sun hotspot JRE1.4.2_17/. We have 4 JVM's which are running on the
> > same machine.
> > These JVM's recieve xml messages from MQ queue which are processed (
> > business logic stores the data from xml into database) and xml replies
> > are sent back to the MQ queue.
> >
> > Hardware
> > 8 dual core - sparc IV
> > 4 single core - sparc III
> >
> > JRE options set on JVM's
> >
> > -server -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xmx768m -Xms768m
> > -XX:MaxNewSize=500m -XX:NewSize=500m -XX:+UseParNewGC
> > -XX:+CMSParallelRemarkEnabled -XX:+UseConcMarkSweepGC
> > -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=128
> >
> > During our stress test we are seeing that CMS collector is trying to
> > start old gen collection very frequently and the cpu usage spikes upto
> > 99% -100% usage.
> > Our stress test included adding a user per second until we reach 2500
> > user limit and then we maintain steady user rate of 2500.
> >
> > Attached are the gc logs from one of the JVM, the PrintGCStats details
> > and GCTimeline graph from GCHisto tool
> >
> > Is there anything I should set so that CMS collector doesn't start so
> > frequently. Also, don't know if increasing the total heap size (to
> > 1GB) will improve this situation.
> >
> > Please provide your comments.
> >
> > thanks
> > vasu..
> >
> >
> > ------------------------------------------------------------------------
> > Windows Live™: Life without walls. Check it out.
> > <http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1b_explore_042009>
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >hotspot-gc-use mailing list
> >hotspot-gc-use at openjdk.java.net
> >http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
> >
> >
>
>
_________________________________________________________________
Rediscover Hotmail®: Get quick friend updates right in your inbox.
http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Updates2_042009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20090421/9ca181c1/attachment.html
More information about the hotspot-gc-use
mailing list