parallel gc versus serial gc

Discussion in 'Java' started by hopehope_123, Dec 17, 2006.

  1. hopehope_123

    hopehope_123 Guest

    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
    hopehope_123, Dec 17, 2006
    #1
    1. Advertising

  2. 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" <> wrote in message
    news:...
    > 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
    >
    Remon van Vliet, Dec 20, 2006
    #2
    1. Advertising

  3. hopehope_123

    Lew Guest

    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
    Lew, Dec 20, 2006
    #3
  4. "Lew" <> wrote in message
    news:...
    > 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
    Remon van Vliet, Dec 20, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. methi
    Replies:
    1
    Views:
    2,635
    Andy Peters
    Jun 2, 2005
  2. Soren
    Replies:
    4
    Views:
    1,250
    c d saunter
    Feb 14, 2008
  3. Vivek Menon
    Replies:
    5
    Views:
    3,336
    Paul Uiterlinden
    Jun 8, 2011
  4. Vivek Menon
    Replies:
    0
    Views:
    1,760
    Vivek Menon
    Jun 10, 2011
  5. Paul Butcher
    Replies:
    12
    Views:
    701
    Gary Wright
    Nov 28, 2007
Loading...

Share This Page