<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Ramki,<br>
<br>
Yes, I am agreed with you. 31 is too large and I have removed the
parameter (using default now). Nevertheless this is not the problem
as the max used age was always 1.<br>
<br>
Since the most (more than 90%) new allocated objects in our
application live for a long time (>1h) we mostly will have
premature promotion.<br>
Is there a way to optimize this?<br>
<br>
I have seen most time, when young gc needs much time (> 6 secs)
there is only one large block in the old gen. If there has been a
cms-old-gen-collection and there are more than one blocks in the old
generation it is mostly (not always) much faster (needs less than
200ms).<br>
<br>
Is it possible that premature promotion can not be done parallel if
there is only one large block in the old gen?<br>
<br>
In the past we have had a problem with fragmentation on this server
but this is gone since we increased memory for it and triggered a
full gc (compacting) every night, like Tony advised us. With setting
the initiating occupancy fraction to 80% we have only a few (~10)
old generation collections (which are very fast) and the heap
fragmentation is low.<br>
<br>
Flo<br>
<br>
<br>
Am 09.01.2012 19:40, schrieb Srinivas Ramakrishna:
<blockquote
cite="mid:CABzyjy=23c+csJ3ffo5c=2VQeXmuiiZ1z+EyVbfgYV5M2MZcCA@mail.gmail.com"
type="cite">Haven't looked at any logs, but setting
MaxTenuringThreshold to 31 can be bad. I'd dial that down to 8,<br>
or leave it at the default of 15. (Your GC logs which must
presumably include the tenuring distribution should<br>
inform you as to a more optimal size to use. As Kirk noted,
premature promotion can be bad, and so can<br>
survivor space overflow, which can lead to premature promotion and
exacerbate fragmentation.)<br>
<br>
-- ramki<br>
<br>
<div class="gmail_quote">On Mon, Jan 9, 2012 at 3:08 AM, Florian
Binder <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:java@java4.info">java@java4.info</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi everybody,<br>
<br>
I am using CMS (with ParNew) gc and have very long (> 6
seconds) young<br>
gc pauses.<br>
As you can see in the log below the old-gen-heap consists of
one large<br>
block, the new Size has 256m, it uses 13 worker threads and it
has to<br>
copy 27505761 words (~210mb) directly from eden to old gen.<br>
I have seen that this problem occurs only after about one week
of<br>
uptime. Even thought we make a full (compacting) gc every
night.<br>
Since real-time > user-time I assume it might be a
synchronization<br>
problem. Can this be true?<br>
<br>
Do you have any Ideas how I can speed up this gcs?<br>
<br>
Please let me know, if you need more informations.<br>
<br>
Thank you,<br>
Flo<br>
<br>
<br>
##### java -version #####<br>
java version "1.6.0_29"<br>
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)<br>
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode)<br>
<br>
##### The startup parameters: #####<br>
-Xms28G -Xmx28G<br>
-XX:+UseConcMarkSweepGC \<br>
-XX:CMSMaxAbortablePrecleanTime=10000 \<br>
-XX:SurvivorRatio=8 \<br>
-XX:TargetSurvivorRatio=90 \<br>
-XX:MaxTenuringThreshold=31 \<br>
-XX:CMSInitiatingOccupancyFraction=80 \<br>
-XX:NewSize=256M \<br>
<br>
-verbose:gc \<br>
-XX:+PrintFlagsFinal \<br>
-XX:PrintFLSStatistics=1 \<br>
-XX:+PrintGCDetails \<br>
-XX:+PrintGCDateStamps \<br>
-XX:-TraceClassUnloading \<br>
-XX:+PrintGCApplicationConcurrentTime \<br>
-XX:+PrintGCApplicationStoppedTime \<br>
-XX:+PrintTenuringDistribution \<br>
-XX:+CMSClassUnloadingEnabled \<br>
-Dsun.rmi.dgc.server.gcInterval=9223372036854775807 \<br>
-Dsun.rmi.dgc.client.gcInterval=9223372036854775807 \<br>
<br>
-Djava.awt.headless=true<br>
<br>
##### From the out-file (as of +PrintFlagsFinal): #####<br>
ParallelGCThreads = 13<br>
<br>
##### The gc.log-excerpt: #####<br>
Application time: 20,0617700 seconds<br>
2011-12-22T12:02:03.289+0100: [GC Before GC:<br>
Statistics for BinaryTreeDictionary:<br>
------------------------------------<br>
Total Free Space: 1183290963<br>
Max Chunk Size: 1183290963<br>
Number of Blocks: 1<br>
Av. Block Size: 1183290963<br>
Tree Height: 1<br>
Before GC:<br>
Statistics for BinaryTreeDictionary:<br>
------------------------------------<br>
Total Free Space: 0<br>
Max Chunk Size: 0<br>
Number of Blocks: 0<br>
Tree Height: 0<br>
[ParNew<br>
Desired survivor size 25480392 bytes, new threshold 1 (max 31)<br>
- age 1: 28260160 bytes, 28260160 total<br>
: 249216K->27648K(249216K), 6,1808130 secs]<br>
20061765K->20056210K(29332480K)After GC:<br>
Statistics for BinaryTreeDictionary:<br>
------------------------------------<br>
Total Free Space: 1155785202<br>
Max Chunk Size: 1155785202<br>
Number of Blocks: 1<br>
Av. Block Size: 1155785202<br>
Tree Height: 1<br>
After GC:<br>
Statistics for BinaryTreeDictionary:<br>
------------------------------------<br>
Total Free Space: 0<br>
Max Chunk Size: 0<br>
Number of Blocks: 0<br>
Tree Height: 0<br>
, 6,1809440 secs] [Times: user=3,08 sys=0,51, real=6,18 secs]<br>
Total time for which application threads were stopped:
6,1818730 seconds<br>
_______________________________________________<br>
hotspot-gc-use mailing list<br>
<a moz-do-not-send="true"
href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a><br>
<a moz-do-not-send="true"
href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use"
target="_blank">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a><br>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>