<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
In the gc log it seems that there is always running the same garbage
collection.<br>
For example:<br>
$ zcat out_err.log.gz | grep 20480M | tail<br>
2011-11-28T19:13:19.482+0100: [GC cleanup 14515M->14515M(20480M),
0.1370060 secs]<br>
[ 16394M->12914M(20480M)]<br>
[ 16394M->12914M(20480M)]<br>
2011-11-28T19:17:12.509+0100: [GC cleanup 15582M->15582M(20480M),
0.1387230 secs]<br>
[ 16394M->12914M(20480M)]<br>
[ 16394M->12914M(20480M)]<br>
[ 16394M->12914M(20480M)]<br>
2011-11-28T19:21:06.089+0100: [GC cleanup 12978M->12978M(20480M),
0.1344170 secs]<br>
[ 16394M->12914M(20480M)]<br>
[ 16394M->12914M(20480M)]<br>
<br>
Therefore I assume this might be a bug ;-)<br>
You can download the whole log at:
<a class="moz-txt-link-freetext" href="http://java4.info/g1/out_err.log.gz">http://java4.info/g1/out_err.log.gz</a><br>
<br>
I don't think that we still have the logs of that very long gc, but
I will have a look for it at monday.<br>
Furthermore I do not think that we have logged there much details of
the gc. But I know that this happend on a very special server, which
contains more the 30gb of references (yes, just references to other
objects). If we run it with CompressedOops we reduce the memory
useage to nearly 50%.<br>
<br>
Flo<br>
<br>
<br>
<br>
Am 10.12.2011 01:34, schrieb Srinivas Ramakrishna:
<blockquote
cite="mid:CABzyjynoUfeND2NPoFCeDONcq9=yX1XwUVzzhuO0BZX_Rt=fcw@mail.gmail.com"
type="cite"><br>
<br>
A couple of things caught my eye....<br>
<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
On 12/05/2011 02:19 PM, Florian Binder wrote:<br>
>> I assume you know when the data will be dropped and
reinitialized,<br>
>> right? Can you do a Full GC (with System.gc())
after you re-initialize<br>
>> the heap. This typically helps a lot with CMS.<br>
> Yes, this is exactly what we are trying at this time
;-)<br>
> Either this Full-GC pauses are very long (60-300
seconds) they are much<br>
> shorter than after a CMS-failure (when they take
sometimes more than<br>
> 4000 seconds ;-)) and we can define when they occure.<br>
</div>
</blockquote>
<div><br>
A full GC that takes an hour is definitely a bug. Have you
logged that bug?<br>
Or at least share the GC log? What's the version of the JDK
that this behaviour<br>
was seen with?<br>
<br>
</div>
<div>... <br>
</div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
> Furthermore this should not increase the
total-heap-space:<br>
> <a moz-do-not-send="true"
href="http://java4.info/g1/all.png" target="_blank">http://java4.info/g1/all.png</a><br>
</div>
</blockquote>
<div><br>
Remember that jconsole asynchronously samples the heap, whose
size is<br>
read "with possible glitches". Rather, you should probably
rely on the GC log in order to assess<br>
the heap size after each GC event, rather than the
asynchronous samples from<br>
jconsole. I myself have not had the chance to look at yr GC
logs to see<br>
what that indicated wrt the size of Eden and of the Heap.<br>
<br>
-- ramki<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>