Skip to main content

GC Performance problem

6 replies [Last post]
Joined: 2006-11-22


I am working on WebLogic(for the first time) with a sun JVM on a 8 CPU solaris machine, we have set the GC algorithm as,

"-Xms2048m -Xmx2048m -XX:NewSize=576m -XX:MaxNewSize=576m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:SurvivorRatio=8 -Xverify:none -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintTenuringDistribution -XX:+UseParallelGC "

The problem is The FULL GC takes consistently between 15 - 20 sec, firstly is that a concern?

We see that the heap is used up to 1.9 GB before it GC's

The CPU Utilzation on box is not high below 40% on an average.

Is using the "Concurrent Low Pause Collector" a good option in this case?

Please assist.

Thanks in advance.

Following GC trace,

4028.217: [GC 1425000K->1003932K(2012352K), 0.4191734 secs]
4028.637: [Full GC[Unloading class sun.reflect.GeneratedMethodAccessor655]
[Unloading class jsp_servlet._web_45_inf._apcwp._ptrck._jsp.__ptstatementpdf]
[Unloading class sun.reflect.GeneratedMethodAccessor1726]
[Unloading class jsp_servlet._web_45_inf._apfa._opnac._jsp.__ocainput]
[Unloading class jsp_servlet._web_45_inf._apfa._hkgcb._hkcareer._jsp.__main]
[Unloading class jsp_servlet._web_45_inf._apfa._hkgcb._hkcareer._jsp.__job]
[Unloading class jsp_servlet._web_45_inf._apcwp._ptrck._jsp.__ptstatement]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor290]
[Unloading class sun.reflect.GeneratedMethodAccessor1725]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor356]
[Unloading class sun.reflect.GeneratedMethodAccessor2253]
[Unloading class sun.reflect.GeneratedMethodAccessor653]
[Unloading class jsp_servlet._web_45_inf._jba._common._jsp.__cantdo]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor357]
[Unloading class jsp_servlet._web_45_inf._apeba._ebrk_reg._rsp._jsp.__screen100]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor355]
[Unloading class jsp_servlet._web_45_inf._apcwp._myprf._jsp.__profilesummary]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor323]
[Unloading class jsp_servlet._web_45_inf._jba._ada._jsp.__adaprintfriendly]
[Unloading class sun.reflect.GeneratedMethodAccessor654]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor335]
[Unloading class jsp_servlet._web_45_inf._apfa._hkgcb._itvisa._jsp.__itvisaempdet]
[Unloading class jsp_servlet._web_45_inf._apfa._hkgcb._hkcareer._jsp.__generic]
[Unloading class sun.reflect.GeneratedMethodAccessor652]
[Unloading class sun.reflect.GeneratedMethodAccessor1966]
[Unloading class jsp_servlet._web_45_inf._aptc._fxrates._jsp.__fxrateview]
[Unloading class sun.reflect.GeneratedMethodAccessor2252]
[Unloading class jsp_servlet._web_45_inf._apfa._hkgcb._itvisa._jsp.__dummy]
[Unloading class jsp_servlet._web_45_inf._jso._uidn._jsp.__successcinpin]
[Unloading class jsp_servlet._web_45_inf._apfa._hkgcb._hkcareer._jsp.__service]
[Unloading class jsp_servlet._web_45_inf._apfa._hkgcb._hkcareer._jsp.__job_list_category_unit]
[Unloading class jsp_servlet._web_45_inf._aptc._fxrates._jsp.__calculate]
[Unloading class jsp_servlet._web_45_inf._jba._scdp._jsp.__displaynopayeeinlistscreen]
1003932K->862215K(2015232K), 15.3721435 secs]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2006-11-22


Thanks again for your response.

I managed to convince to change the heap size a bit,


Hope this looks a bit better we will be monitoring the env with these settings and see how much heap is actually used and probably reduce the heap size after that, also the size of the young generation.

Please let me know know your suggestions about these settings.


Joined: 2004-01-07

seems good to me - looking forward to hear your experiences.

Joined: 2004-01-07

1.) no stress - you can't expect a reply in less than 4 hours for free. In general 4-hout turnarround contracts are VERY expensive ;)

2.) Now to your GC problem ;-)

* You could try the paralell collector for the old collection: -XX:+UseParallelOldGC
* You set your hep fix to 1.9GB - is this really nescesary?
Of course a 2GB heap takes some time to GC - you sacrifice responsiveness for throughput.
* Do you need such a large young generation? I wonder wether this is really fast ;)

Could you retry your app with my values, just to be curious how they perform:

"-Xmx2048m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90"

I know this is a bit drastic but if you don't have load problems anyway ... give it a try ;)

lg Clemens

Joined: 2006-11-22


Thanks for your response.

This problem I referred to is on a production box, I have newly joined this banking organization. It seems that the heap values were suggested by some BEA experts, so are the young generation sizes.

But will definetly give your suggestion a try.

just couple of questions (I am a bit new to SUN JVM)
1) What do you suggest about the following parameters,

"-Xms2048m -Xmx2048m

Please do let me know if this will be better than what it currently is

2) Is'nt "+UseParNewGC" enabled by default?

Thanks again.

Joined: 2004-01-07

Hi again,

1.) should be better although the heap size remains the same there is a lot more paralelism.

> only affects yozung generation as far as I know.

2.) Maybe. Don't know to be honest. Useing it explicitly won't hurt ;). However young/new generation isn't your problem as it seems.

3.) The GC log displays only a single collection which does not seem to be a full GC ... could that be?
As far as I know the Sun-JVM prints out "FULL GC...", it seems a minor collection takes that long.
I really would try to reduce the size of teh young generation...

lg Clemens

Joined: 2006-11-22

hi please can somebody assist ?