Re: java

Hi Robert ,

thanks for your help.

These are the garbage collector times . In order to have a benefit with parallel gc , i think the application time value must ebe higher than the serial :

serial:

Application time: 0.1951595 seconds
0.000: [GC 0.000: [DefNew: 144640K->129K(149120K), 0.0116972 secs] 144640K->129K(456320K), 0.0119153 secs]
Total time for which application threads were stopped: 0.0231885 seconds
Application time: 0.0443557 seconds
0.070: [GC 0.070: [DefNew: 144769K->129K(149120K), 0.0022509 secs] 144769K->129K(456320K), 0.0024223 secs]
Total time for which application threads were stopped: 0.0158733 seconds

parallel:

Application time: 0.1793080 seconds
0.000: [GC [PSYoungGen: 116736K->272K(136192K)] 116736K->272K(443392K), 0.0040205 secs]
Total time for which application threads were stopped: 0.0137073 seconds
Application time: 0.0356463 seconds
0.050: [GC [PSYoungGen: 117008K->320K(136192K)] 117008K->320K(443392K), 0.0178077 secs]
Total time for which application threads were stopped: 0.0275291 seconds
Application time: 0.0329056 seconds
0.110: [GC [PSYoungGen: 117056K->272K(136192K)] 117056K->272K(443392K), 0.0028026 secs]
Total time for which application threads were stopped: 0.0120788 seconds

Kind Regards,
hope

Robert Klemme wrote:
> On 17.12.2006 12:14, hopehope_123 wrote:
> > We use oracle application server and have some pausing problems inside
> > the java vm. The problem shows itself as pausings of executions , when
> > clients start to get late responses ( here lat e means < 4 sec. ) , i
> > see more than 10 garbage collector operations . The client applications
> > are web services and do database queries. The java process ( the os is
> > sun solaris) , according to the prstat , has > 1000 threads inside ,
> > and during the garbage collectiong phase , consumes more than 60% cpu
> > time. ( the server has 2 cpus - 2 gb. ram) The java process uses the
> > following parameters:
>
> 2GB for a Solaris box seems a bit low - especially if it has to handle
> traffic from 1000 clients concurrently.
>
> > What i think is , the reason of the suspensions is garbage collector
> > activity.
> >
> > In order to decrease the time that cause pausing , i either increase
> > the virtual memory allocated by the java process , or change the
> > garbage collector method. Before adding up mor memory to teh system ,
> > i want to be sure the effect of changing garbag ecollector methodology.
> >
> > The gc used here is serial garbage collector , in order to speed it up
> > , the documents say that parallel garbage collector is used.
> >
> > I write a small test program . This program creates 1000 threads .
> > Each thread creates objects by using new in a loop , and this causes
> > the garbage collector runs heavily in order to clean teh garbages. And
> > i run the program bu using different garbage collectors but
> > unfortunately , i dont see great difference beetween serial and
> > parallel gc ,and serial gc is faster.
> >
> > Why does this so?
>
> Serial GC stops all other threads and does only GC - this is more
> efficient than parallel GC - you can find articles about this on
> java.sun.com - I don't have a link handy.
>
> Parallel GC is overall slower but has smaller stop the world phases
> which leads to better responsiveness.
>
> > Serial gc:
> >
> > timex java -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
> > -Xmx450m -Xms450m -XX:+PrintGCApplicationConcurrentTime
> > -XX:+PrintGCApplicationStoppedTime -XX:+UseSerialGC test > test1
> >
> > real 23.48
> > user 3:26.67
> > sys 4.33
> >
> >
> > parallel gc:
> >
> > timex java -server -verbose:gc -XX:+PrintGCDetails
> > -XX:+PrintGCTimeStamps -Xmx450m -Xms450m
> > -XX:+PrintGCApplicationConcurrentTime
> > -XX:+PrintGCApplicationStoppedTime -XX:+UseParallelGC test > test1
> >
> > real 24.35
> > user 3:24.68
> > sys 30.95
>
> Note that there is a whole bunch of other GC parameters that affect
> performance. You can for example change the ration between young and
> old generation heap space etc.
>
> robert
Received on Sun Dec 17 2006 - 16:16:11 CST