Java6u7 : 2 very long Parallel GC (24&30min) without any specific reason

[David Tavoularis]

Hi Jon,

Yes, I set the maximum heap size on the command line. Please note that we are using ms=mx=20GB on a 64GB server.

/xxx/jdk1.6.0_07/bin/sparcv9/java -server -Xms20000m -Xmx20000m -cp '' -Djava.ext.dirs=/opt/xxxxx/jar -Dsun.rmi.transport.tcp.handshakeTimeout=480000 -Dsun.rmi.dgc.client.gcInterval=900000 -Dsun.rmi.dgc.server.gcInterval=900000 -XX:NewSize=3990m -XX:MaxNewSize=3990m -XX:+UseParallelGC -XX:+AggressiveHeap -XX:MaxPermSize=512m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -Xloggc:/opt/xxxxx/logs/gc_20081013111157.log com.my.class

> This says that the VM is doing lots of waiting.  Do you have
> more than 1 VM running on this machine?  Or other applications
> that are using lots of physical memory?  The much larger
> real time often indicates swapping.
There are only 2 other JVMs on the server (using 22GB & 13GB), so the total allocated memory is 20+22+13=55GB, there should be no swapping.
But I will check if there are any defectuous RAM on the server.

> Using this setting should limit the growth  of the heap
> so that you stay below the 10min pause.   You should be
> able to see the size of the heap in the GC logs
> (young gen + old (tenured) gen).
I do not understand, does it mean that ms and mx values from command line will not be taken into account ?
Here ms=mx, so I do not expect any change in the heap size.
We also defined on the command line new=4GB, so old=16GB (approximately), according to GC logs.


-- 
David

Le Mon, 13 Oct 2008 17:46:16 +0200, Jon Masamitsu <Jon.Masamitsu at sun.com> a écrit:

> David,
>
> Are you setting the maximum heap size on your command line?
> If not, you may be getting a larger maximum by default.  That
> value has been changed on 64 bit platforms.  It used to be 1g
> (which was ok for 32 bit platforms but makes less
> sense for 64 bit platforms).   Try -Xmx1g which will give you
> the old behavior.
>
> On 10/13/08 06:37, David Tavoularis wrote:
>> Hi,
>>
>> We had 2 very long duration of the Full GC (Parallel GC) running with Java 6u7 (64-bit Solaris), where GC took 24min and then 30min.
>> Usually, Full GC would hardly take more than 2 minutes.
>>
>> We also noticed that the "real" measurement usually comes close to the sum of the "user" and "sys" measurement, but here it outpasses the figures, see :
>> user=47.85 sys=9.84, real=1450.70 secs
>
> This says that the VM is doing lots of waiting.  Do you have
> more than 1 VM running on this machine?  Or other applications
> that are using lots of physical memory?  The much larger
> real time often indicates swapping.
>
>>
>> Any idea what to check from here ?
>>
>>
>> As a workaround, I would like to implement the property "-XX:MaxGCPauseMillis=60000" (10min max for a Full GC). Do you think it is a good idea ?
>>
>
> Using this setting should limit the growth  of the heap
> so that you stay below the 10min pause.   You should be
> able to see the size of the heap in the GC logs
> (young gen + old (tenured) gen).
>
>
>> Thanks in advance
>>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>