GC minor collection takes much too long

Hello,

wie have an web-application which runs within a JRUN-Container. Sometimes it happens that the application is quite slow or does not respond any longer. I assume that this is caused by excessive Minor Garbage Collection. Usually Minor GC takes less than 50ms for our application, but when the problems occur Minor GC takes longer than 10 seconds. I had activated GC-Logging and saw the following:

304487.032: [Full GC 836349K->821287K(1305152K), 1.9928393 secs]

304489.324: [GC 909786K->822856K(1305536K), 10.2081559 secs]

304499.532: [Full GC 822856K->822785K(1305536K), 1.1174568 secs]

304501.073: [GC 958017K->825665K(1305536K), 10.1765759 secs]

304511.668: [GC 960769K->825903K(1305472K), 10.3207171 secs]

304522.386: [GC 961007K->826122K(1305984K), 10.1663418 secs]

304532.983: [GC 961223K->825253K(1305984K), 10.2193920 secs]

304543.601: [GC 961381K->825360K(1306240K), 10.2034775 secs]

304554.199: [GC 961488K->824932K(1306240K), 10.1546134 secs]

304564.365: [GC 826291K->824924K(1306368K), 10.2652784 secs]

304574.630: [Full GC 824924K->824894K(1306368K), 1.1122661 secs]

304576.173: [GC 961790K->826015K(1306624K), 10.1681785 secs]

304586.749: [GC 962908K->826608K(1306624K), 10.1370318 secs]

304597.285: [GC 964011K->827312K(1306944K), 10.1685827 secs]

304607.849: [GC 964714K->826349K(1306944K), 10.2140155 secs]

304618.570: [GC 964397K->827947K(1307072K), 10.1759835 secs]

304629.231: [GC 965992K->826908K(1307072K), 10.1724497 secs]

304639.417: [GC 829233K->826742K(1307200K), 10.1317872 secs]

304649.549: [Full GC 826742K->826715K(1307200K), 1.1164076 secs]

304651.065: [GC 965274K->828000K(1307328K), 10.1325777 secs]

304661.653: [GC 966560K->829308K(1307328K), 10.2799643 secs]

304672.387: [GC 968121K->831352K(1307328K), 10.3042556 secs]

304682.980: [GC 935255K->831011K(1306816K), 10.7194860 secs]

304693.699: [Full GC 831011K->823777K(1306688K), 1.9301172 secs]

304696.028: [GC 961312K->825305K(1306816K), 15.4142203 secs]

304711.920: [GC 962841K->825340K(1306816K), 12.2380482 secs]

304724.634: [GC 963259K->825178K(1307136K), 11.8191080 secs]

304736.951: [GC 963098K->826016K(1307136K), 10.4875640 secs]

The Java-process runs with following parameters:

java.args=-Xms1024m -Xmx1280M -server -Dsun.io.useCanonCaches=false -XX:MaxPermSize=128m -XX:+UseParallelGC -DJINTEGRA_NATIVE_MODE -DJINTEGRA_PREFETCH_ENUMS -Dcoldfusion.rootDir={application.home}/ -Xloggc:D:\\gclog

What can be done to avoid the long running Minor GC?

I would be grateful for any help!

Thanks,

Thomas

[2798 byte] By [sunteam@sieerla] at [2007-11-26 21:18:09]
# 1

Thomas,

Hi. First, can you please confirm a few things?

(a) You have enough physical memory to hold the JVM and heap in it (i.e., the long young GCs are not caused by paging).

(b) You are not running any other heavy-weight processes on that machine that might be stealing cycles.

Also, a few question

(a) What type of machine you're running on (i.e., how many and what type of CPUs do you have)?

(b) Do you get the same results if you set -XX:ParallelGCThreads=1?

(c) Which JVM version do you use? Have you tried the latest (6.0)?

Tony, HS GC Group

TonyPrintezisa at 2007-7-10 2:56:55 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 2

a) The Machine has 4GB of Memory. This should be sufficinde in comparison to the configured Heap.

b) No other heavy weight processes are running.

to your questions:

a) 2 x Intel Opteron Dual Core 2,2 Ghz

b) Have not yet tried this setting

c) 1.4.2_03-b02

Regards,

Thomas

sunteam@sieerla at 2007-7-10 2:56:55 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 3

Thomas,

Thanks for the info. We have seen a few cases of GC pause times going up in the past and we have resolved a lot of them. You're using 1.4.2_03 which is a pretty old release. Have you tried the latest 1.4.2 (which is _13)? Also, is it impossible to move to a more recent release (like 6.0)?

Tony

TonyPrintezisa at 2007-7-10 2:56:55 > top of Java-index,Java HotSpot Virtual Machine,Specifications...