On Aug 12, 2008, at 2:21 PM, pc3 wrote:
How does this look in terms of my GC settings?
Note the Full GC taking 7-9 sec... and yes, our users are feeling it.
9294.839: [Full GC [PSYoungGen: 5669K->0K(518848K)] [PSOldGen:
2270713K->2036966K(3495296K)] 2276382K->2036966K(4014144K) [PSPermGen:
132633K->132553K(262144K)], 9.6645590 secs]
<snip>
Kevan Miller wrote:
On Aug 9, 2008, at 12:09 AM, Pete Clark wrote:
Finally, here are our startup opts as it pertains to GC if it helps:
-XX:+HeapDumpOnOutOfMemoryError -XX:PermSize=256m -
XX:MaxPermSize=256m
-Xmx5120m -Xms5120m -Xss128k -XX:ParallelGCThreads=20
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=8
-XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31
-XX:+AggressiveOpts -Xloggc:/var/tmp/gc.log
<snip>
What's the behavior like, if you run without the GC tuning parameters?
Wondering how much these tuning parms are actually buying you... E.g:
-XX:+HeapDumpOnOutOfMemoryError -XX:PermSize=256m -XX:MaxPermSize=256m
-Xmx5120m -Xms5120m -Xss128k -Xloggc:/var/tmp/gc.log
Do you have any very large objects? How much physical memory do your
servers have?
I doubt that 20 parallel GC threads are necessary, but also doubt that
they are causing any harm...
As I mentioned, I'm not really up-to-speed with current (1.5/1.6) GC
tuning parameters/behaviors. One thing to explore is how to keep
objects out of your tenured space (and in young space). Hmm. Have you
tried -XX:+UseParallelOldGC?
I assume your problem is in the GC of your tenured space (but that's
kind of a big assumption... ;-)
--kevan
