frequent CMS collections/ CPU spike/ Hotspot JRE1.4.2_17/

Jon Masamitsu Jon.Masamitsu at Sun.COM
Mon Apr 20 20:49:29 PDT 2009


vasu ts wrote On 04/20/09 20:18,:

> 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.
>
What you say is likely true but when the young gen gets collected there
has to be space in the tenured gen for anything that survives the young
gen collection so you need a tenured gen that also meets the needs of
your application.

> 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).


No, the young gen does not necessarily need more space. The way that
the GC works is that allocations are done until a generation is full and
then a collection is done. Unless you stop doing allocations, you're
always going to have the young gen fill up and have to do GC's.

>
> 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.
> Check it out.
> <http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Updates2_042009>



_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use



More information about the hotspot-gc-dev mailing list