<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Yes!<br>
You are right!<br>
I have a lot of page faults when gc is taking so much time.<br>
<br>
For example (sar -B):<br>
00:00:01 pgpgin/s pgpgout/s fault/s majflt/s<br>
00:50:01 0,01 45,18 162,29 0,00<br>
01:00:01 0,02 46,58 170,45 0,00<br>
01:10:02 25313,71 27030,39 27464,37 0,02<br>
01:20:02 23456,85 25371,28 13621,92 0,01<br>
01:30:01 22778,76 22918,60 10136,71 0,03<br>
01:40:11 19020,44 22723,65 8617,42 0,15<br>
01:50:01 5,52 44,22 147,26 0,05<br>
<br>
What is this meaning and how can I avoid it?<br>
<br>
<br>
Flo<br>
<br>
<br>
<br>
Am 09.01.2012 20:33, schrieb Chi Ho Kwok:
<blockquote
cite="mid:CAG7eTFrzjtWPpHcvJeG86nKEUBFV3j1nzzO00t7O_fWPnT6JyQ@mail.gmail.com"
type="cite">Just making sure the obvious case is covered: is it
just me or is 6s real > 3.5s user+sys with 13 threads just
plain weird? That means there was 0.5 thread actually running on
the average during that collection.
<div><br>
</div>
<div>Do a sar -B (requires package sysstat) and see if there were
any major pagefaults (or indirectly via cacti and other
monitoring tools via memory usage, load average etc, or even via
cat /proc/vmstat and pgmajfault), I've seen those cause these
kind of times during GC.</div>
<div><br>
</div>
<div><br>
</div>
<div>Chi Ho Kwok<br>
<div><br>
</div>
<div>
<div class="gmail_quote">On Mon, Jan 9, 2012 at 12:08 PM,
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>
</div>
</div>
</blockquote>
<br>
</body>
</html>