<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Matt,<br>
<br>
As Ramki indicated fragmentation might be an issue. As the
fragmentation<br>
in the old generation increases, it takes longer to find space in the
old generation<br>
into which to promote objects from the young generation. This is
apparently not<br>
the problem that Wayne is having but you still might be hitting it. If
you can<br>
connect jconsole to the VM and force a full GC, that would tell us if
it's<br>
fragmentation.<br>
<br>
There might be a scaling issue with the UseParNewGC. If you can use<br>
-XX:-UseParNewGC (turning off the parallel young<br>
generation collection) with -XX:+UseConcMarkSweepGC
the pauses<br>
will be longer but may be more stable. That's not the solution but
just part<br>
of the investigation.<br>
<br>
You could try just -XX:+UseParNewGC without -XX:+UseConcMarkSweepGC<br>
and if you don't see the growing young generation pause, that would
indicate<br>
something specific about promotion into the CMS generation.<br>
<br>
UseParallelGC is different from UseParNewGC in a number of ways<br>
and if you try UseParallelGC and still see the growing young generation<br>
pauses, I'd suspect something special about your application.<br>
<br>
If you can run these experiments hopefully they will tell<br>
us where to look next.<br>
<br>
Jon<br>
<br>
<br>
On 05/12/10 15:19, Matt Fowles wrote:
<blockquote
cite="mid:AANLkTik0Ft_M27QE4OGUi0Ycn1Fe82bUkFw0znEgch09@mail.gmail.com"
type="cite">
<pre wrap="">All~
I have a large app that produces ~4g of garbage every 30 seconds and
am trying to reduce the size of gc outliers. About 99% of this data
is garbage, but almost anything that survives one collection survives
for an indeterminately long amount of time. We are currently using
the following VM and options:
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
-verbose:gc
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-XX:+PrintGCTaskTimeStamps
-XX:+PrintTenuringDistribution
-XX:+PrintCommandLineFlags
-XX:+PrintReferenceGC
-Xms32g -Xmx32g -Xmn4g
-XX:+UseParNewGC
-XX:ParallelGCThreads=4
-XX:+UseConcMarkSweepGC
-XX:ParallelCMSThreads=4
-XX:CMSInitiatingOccupancyFraction=60
-XX:+UseCMSInitiatingOccupancyOnly
-XX:+CMSParallelRemarkEnabled
-XX:MaxGCPauseMillis=50
-Xloggc:gc.log
As you can see from the GC log, we never actually reach the point
where the CMS kicks in (after app startup). But our young gens seem
to take increasingly long to collect as time goes by.
The steady state of the app is reached around 956.392 into the log
with a collection that takes 0.106 seconds. Thereafter the survivor
space remains roughly constantly as filled and the amount promoted to
old gen also remains constant, but the collection times increase to
2.855 seconds by the end of the 3.5 hour run.
Has anyone seen this sort of behavior before? Are there more switches
that I should try running with?
Obviously, I am working to profile the app and reduce the garbage load
in parallel. But if I still see this sort of problem, it is only a
question of how long must the app run before I see unacceptable
latency spikes.
Matt</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
hotspot-gc-use mailing list
<a class="moz-txt-link-abbreviated" href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a>
<a class="moz-txt-link-freetext" href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a></pre>
</blockquote>
</body>
</html>