f



parallel gc versus serial gc

Hi ,

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:

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:

 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



and here is the test code:

(I run this test on a bigger box , 24gb.ram , 6 dual core solaris cpus
)

>cat test.java

import java.util.*;
import java.net.*;
import java.io.*;


 class testTh extends Thread
{
   public int val ;
  public testTh ( int pval) { val=pval; }
    public void run() {
	   int i=0;
	String s  =new String("aaaa");
 	 boolean flag=true;
 	  while (flag)
	 {
		 for (int j=0;j<100000;j++) {
	       		s = new String("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa");
		}
	    i++;
	    if (i>10) flag=false;
	}
	}
}

public class test
{
  public void dene() {
	for ( int j=0;j<1000;j++)
 		(new testTh(j)).start();

	   }
  public static void main(String args[])
   {
        test t = new test();
        t.dene();
}
}

Kind Regards,
hope

0
hopehope_123 (149)
12/17/2006 11:13:05 AM
comp.lang.java.programmer 52714 articles. 1 followers. Post Follow

3 Replies
495 Views

Similar Articles

[PageSpeed] 55

Hello,

First of all, you should make sure your test is a reasonably accurate 
simulation of the actual application. Your test will indeed create a lot of 
objects but these will all reside in the "young/eden" region of the heap and 
will not survive a single garbage collection sweep.

As for garbage collection strategies, consider using the concurrent strategy 
(-XX:+UseConcMarkSweepGC ). Note that this scheme effectively takes away 
some (cpu) resources from your application while it runs in return for 
(much) shorter pause times during GC sweeps.

Finally, having to play around with GC strategies is often needed for high 
load/high concurrency applications, but consider the possibility that you're 
trying to fix a symptom rather than the cause. Your application may be 
creating an excessive amount of new objects and/or use an excessive amount 
of threads that can access live objects. Perhaps a change in design or 
implementation can drastically reduce either and fix the problem rather than 
one of it's symptoms. And on that note, is it really necessary for this 
application to create 1000 looping threads? Note that having a lot of 
threads will always cause context switching overhead so you may want to make 
sure they're actually needed. Consider using Runnable tasks and 
ThreadPoolExecutor, and keep in mind having extra threads only really adds 
to the application performance if there are at least as many physical CPUs 
available to the program.

Regards,

Remon van Vliet

"hopehope_123" <hopehope_123@yahoo.com> wrote in message 
news:1166353985.804893.51870@t46g2000cwa.googlegroups.com...
> Hi ,
>
> 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:
>
> 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:
>
> 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
>
>
>
> and here is the test code:
>
> (I run this test on a bigger box , 24gb.ram , 6 dual core solaris cpus
> )
>
>>cat test.java
>
> import java.util.*;
> import java.net.*;
> import java.io.*;
>
>
> class testTh extends Thread
> {
>   public int val ;
>  public testTh ( int pval) { val=pval; }
>    public void run() {
>    int i=0;
> String s  =new String("aaaa");
>  boolean flag=true;
>    while (flag)
> {
> for (int j=0;j<100000;j++) {
>        s = new String("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa");
> }
>     i++;
>     if (i>10) flag=false;
> }
> }
> }
>
> public class test
> {
>  public void dene() {
> for ( int j=0;j<1000;j++)
>  (new testTh(j)).start();
>
>    }
>  public static void main(String args[])
>   {
>        test t = new test();
>        t.dene();
> }
> }
>
> Kind Regards,
> hope
> 


0
remon (167)
12/20/2006 3:31:43 PM
Remon van Vliet wrote:
> ...  keep in mind having extra threads only really adds
> to the application performance if there are at least as many physical CPUs 
> available to the program.

Not entirely accurate. I/O-bound threads, for example, will spend substantial 
time blocked on I/O and will not need as much execution time, giving other 
threads more opportunity to interleave.

It's more accurate to say that threads might add to performance if the CPU 
pool is not maxed out. Even a single CPU can benefit from multi-threading to a 
degree, depending on the execution profile.

- Lew
0
lew35 (549)
12/20/2006 3:48:38 PM
"Lew" <lew@nowhere.com> wrote in message 
news:Gq6dnSjjdNLKxhTYnZ2dnUVZ_r-onZ2d@comcast.com...
> Remon van Vliet wrote:
>> ...  keep in mind having extra threads only really adds
>> to the application performance if there are at least as many physical 
>> CPUs available to the program.
>
> Not entirely accurate. I/O-bound threads, for example, will spend 
> substantial time blocked on I/O and will not need as much execution time, 
> giving other threads more opportunity to interleave.
>
> It's more accurate to say that threads might add to performance if the CPU 
> pool is not maxed out. Even a single CPU can benefit from multi-threading 
> to a degree, depending on the execution profile.

Very valid point, I was oversimplifying there ;)

Remon 


0
remon (167)
12/20/2006 4:24:59 PM
Reply: