|
View:
New views
2 Messages
—
Rating Filter:
Alert me
|
|
|
Big GC for unknown reasonFirst of all, I dunno is it appropriate to ask gc tuning question here. Please forgive me if I post in wrong place.
Well, I was chat with Sun GC Tuning Team long time ago and seek for gc tuning advise. The team was dismissed. Today, I google Jon Masamitsu and finally get here. :> So, my question is: Any idea why there was a big gc at 51789? We are using jdk1.6.0_04 on windows32 with this set of vm option: c:\progra~1\Java\jdk1.6.0_04\bin\java -server -verbose:gc -XX:+PrintGCDetails -Xloggc:itrade_gc_gc.log -Xms1024M -Xmx1612M -XX:NewSize=128M -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=6 -XX:CMSInitiatingOccupancyFraction=80 -XX:TargetSurvivorRatio=90 -Dcom.sun.management.jmxremote.port=18000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false 51789.930: [Full GC 51789.930: [CMS: 403366K->126465K(917504K), 19.1967956 secs] 430862K->126465K(1032192K), [CMS Perm : 23152K->23072K(23296K)], 19.1972027 secs] [Times: user=0.94 sys=0.17, real=19.19 secs] The heap is around 4x% full at that time and the machine has 8G physical memory. From the logs, it show that it spend 19.19 secs (real), what is user/sys/real? Any info about it? I guess the vm is spending many time on memory swapping but task mgr show that the peak is around 4G. Thanks and Regards, Ken ![]() |
|
|
Re: Big GC with unknow reasonYour perm gen is nearly full
CMS Perm : 23152K->23072K(23296K) so that might be the cause for the collection. Try increasing the initial size of the perm generation with -XX:PermSize=<nnn>. Or maybe the maximum size of the perm gen with -XX:MaxPermSize=<nnn>. The cms collector does not collect the perm gen by default. Add the flag -XX:+CMSClassUnloadingEnabled to turn on the collection of the perm gen. Ken--@... wrote: > First of all, I dunno is it appropriate to ask gc tuning question here. > Please forgive me if I post in wrong place. > > Well, I was chat with Sun GC Tuning Team long time ago and seek for gc > tuning advise. The team was dismissed. Today, I google Jon Masamitsu and > finally get here. :> > > So, my question is: Any idea why there was a big gc at 51789? > > We are using jdk1.6.0_04 on windows32 with this set of vm option: > > c:\progra~1\Java\jdk1.6.0_04\bin\java -server -verbose:gc > -XX:+PrintGCDetails -Xloggc:itrade_gc_gc.log -Xms1024M -Xmx1612M > -XX:NewSize=128M -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC -XX:SurvivorRatio=6 -XX:CMSInitiatingOccupancyFraction=80 > -XX:TargetSurvivorRatio=90 -Dcom.sun.management.jmxremote.port=18000 > -Dcom.sun.management.jmxremote.authenticate=false > -Dcom.sun.management.jmxremote.ssl=false > > 51789.930: [Full GC 51789.930: [CMS: 403366K->126465K(917504K), 19.1967956 > secs] 430862K->126465K(1032192K), [CMS Perm : 23152K->23072K(23296K)], > 19.1972027 secs] [Times: user=0.94 sys=0.17, real=19.19 secs] > > The heap is around 4x% full at that time and the machine has 8G physical > memory. From the logs, it show that it spend 19.19 secs (real), what is > user/sys/real? Any info about it? I guess the vm is spending many time on > memory swapping but task mgr show that the peak is around 4G. See the unix command time(1) for the definitions of user, sys, and real. Not sure what it is on windows. Basically they are user = user application cpu time sys = system cpu time real = wall clock time Yes, it looks like the VM is waiting on something. > > Thanks and Regards, > Ken > > http://www.nabble.com/file/p18085880/2008-06-24_155647.gif > > |
| Free embeddable forum powered by Nabble | Forum Help |