<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Ramki,<br>
<br>
thanks for your answere.<br>
I have compared the gc-log with the jconsole chart and for every
jump of the eden space to zero there is a (young) gc-entry in the
log. So the jconsole chart is right and the scavenger period
suddenly falls (even I am almost sure the application does not
allocate more objects than before).<br>
Thank you for the hint with the TLAB size. I will trying this now.<br>
<br>
Flo<br>
<br>
Am 12.12.2011 20:40, schrieb Srinivas Ramakrishna:
<blockquote
cite="mid:CABzyjy=vtm2QFAqhcNdC85SKogXRZAnuHSC7AvA5Rfc-qQYCKA@mail.gmail.com"
type="cite"><br>
As I said, instead of relying on jconsole's asynchronous heap size
samples, look at the GC log to see<br>
if the inter-scavenge period suddenly falls (i.e. the application
is presumably allocating at a much faster rate<br>
than is normal). If the GC log confirns that, then see if turning
off TLAB resizing (and fixing it to a reasonable<br>
value) makes any difference.<br>
<br>
Your existing GC logs should be sufficient to answer the first
part of the question above.<br>
<br>
best.<br>
-- ramki<br>
<br>
<div class="gmail_quote">On Mon, Dec 12, 2011 at 11: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">
<div bgcolor="#FFFFFF" text="#000000"> Tony,<br>
<br>
As you have seen at the jconsole-screenshot the app does
make very few garbage. It is optimized to make no garbage.
But suddenly there seems to be every 90 seconds about 4 gb
of (new) garbage (even the load of the app does not change).
Therefore I thought it might be the g1-collector. I will try
to reproduce this senario an have a closure look on it.<br>
<br>
Flo<br>
<br>
Am 12.12.2011 15:46, schrieb Tony Printezis:
<div>
<div class="h5">
<blockquote type="cite"> Florian,<br>
<br>
Not sure what you mean by "the same GC". It is because
the space transition looks like:
16394M->12914M(20480M)? This is normal. Heap
occupancy reaches 16394M, GC happens, heap occupancy
goes down to 12914M. Next time it happens, the heap
will have new objects. This is how GCs work.<br>
<br>
Tony<br>
<br>
On 12/09/2011 09:08 PM, Florian Binder wrote:
<blockquote type="cite"> 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
moz-do-not-send="true"
href="http://java4.info/g1/out_err.log.gz"
target="_blank">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 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>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
hotspot-gc-use mailing list
<a moz-do-not-send="true" href="mailto:hotspot-gc-use@openjdk.java.net" target="_blank">hotspot-gc-use@openjdk.java.net</a>
<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>
</pre>
</blockquote>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>