Full Garabage Collection every minute in oc4j_soa instance

Question

It looks like a Full GC cycle is run exactly every minute on a IDLE BPEL instance that does not have any instances. This is a basic 10.1.3.1.0 BPEL install with no Out of the box parameters modified / tuned. Is this a known issue / bug with a fix ?
Also, we have 3 - 5 Asnyc BPEL Processes that involve human workflow. The invocation rate of these workflows is medium (100 instances per hour),but the instances may last long due to human workflow. What would be the recommended settings for these in terms of worker, invoker and dispatcher threads, DB Connections etc? Is there any tuning guide/ spreadsheet available for computation of optimum values ?
$ jstat -gcutil 7123 60000
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 62.95 29.18 11.66 99.66 651 13.801 62 62.792 76.593
18.75 0.00 86.85 11.78 99.67 666 14.103 63 63.845 77.948
0.00 25.00 71.48 10.95 99.63 681 14.404 64 64.908 79.312
0.00 41.97 54.68 11.08 99.64 697 14.722 65 65.900 80.622
0.00 41.97 30.84 11.21 99.65 713 15.043 66 66.853 81.897
0.00 41.97 7.20 11.33 99.66 729 15.352 67 67.815 83.168
87.81 0.00 75.06 10.92 99.64 744 15.652 68 68.818 84.469
65.86 0.00 43.25 11.04 99.64 760 15.984 69 69.798 85.782
84.94 0.00 82.86 11.23 99.68 776 16.292 70 70.776 87.068
59.61 0.00 1.74 11.41 99.69 792 16.606 71 71.758 88.364
0.00 25.00 67.50 10.94 99.65 807 16.897 72 72.776 89.673
0.00 62.95 23.52 11.06 99.65 823 17.219 73 73.728 90.947
$ top -p 7123
7123 vvedula 17 0 1491m 338m 46m S 3.0 16.7 6:45.31 java => 3% CPU usage

Answer 1

Thanks for the replies. Let me clarify a few things:
1) We've tried setting -Xms to -Xmx (a long time ago, so maybe it's time to revisit), but doing so caused our app to exhibit other strange behavior due to the fact that no full GCs were ever done until all the allocated memory was exhausted. These full GCs, when finally triggered, ended up taking quite some time due to the fact that there was a lot of compaction (or attempted compaction) going on.
2) I don't have a problem with doing full GCs (I use the term full GC because both a young and old generation GC happens at every full GC), but I have a problem with the full GCs happening every 2 or 3 seconds and taking up 100% cpu for minutes (because the concurrent phases would run back-to-back for every full GC). Especially when the app has 1/10th the volume of our other app which does a young gc every 20s or so and a full gc every 5 or 6 minutes.
We've gone ahead and set the initial heap size to -Xms5g for today's run. We initially went without setting -Xms (again, just like our other instance) and we started seeing full GCs almost immediately as the JVM did not want to allocate more heap. We then went with -Xms2g which delayed the full GCs for a few hours until the used heap got close to the allocated heap. Full GCs then kicked in for cycles (15 or 30 mins long) until the JVM increased the heap by a few hundred mb each time.
As I've stated, I'm struggling with the fact that we have another instance of the application that does not exhibit this behavior and does not have -Xms set at all. And the only thing I know that is different is that during startup, the amount of data we load is quite large (~6-8gb) and so our "min size" is already pretty large before starting to handle additional volume. Hopefully setting -Xms to 5g will replicate the starting point of the original instance.
I'll respond back with updates.
Thx,
Josh
Edited by: user10720003 on Aug 12, 2009 4:15 AM