<div dir="ltr"><div class="gmail_extra">Hi Kirk,</div><div class="gmail_extra">I know that it is questioned also on the other list, where I will continue to discuss potential better settings, but I can tell you that the workload is really reproducible, as this system measures its data ingress and the rate was close to equal. Data egress was radically different.</div><div class="gmail_extra">My main concern here on hotspot-gc-dev is that the defaults produced a bad result. Plus I have the feeling the GC optimizes in the wrong direction (shrinking eden instead of increasing eden).</div><div class="gmail_extra">I will come back to this list when we manually figured out good settings.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Fabian<br>
<br><div class="gmail_quote">On Sun, Dec 20, 2015 at 7:38 PM, <a href="mailto:kirk@kodewerk.com">kirk@kodewerk.com</a> <span dir="ltr"><<a href="mailto:kirk@kodewerk.com" target="_blank">kirk@kodewerk.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Fabian,<div><br></div><div>I don’t think the experimentation with your app is over. I don’t think the differences between the two runs can easily be dismissed as the result of changing the values of a few flags. In the first relatively short run, reference processing times clearly dominated resulting in Eden being shrunk in a feeble attempt to meet the pause time goal. I don’t think that the shrinkage in reference processing time cannot be solely attributed to turning on parallel reference processing. It seems as if something else changed. At any rate, I believe you should relax the minimum Eden size from 25%. I have posted a number of charts which anyone should be able to see @ <a href="https://drive.google.com/a/jclarity.com/file/d/0B6IuyTuhCQTPUGpFcDA4bF8zbUk/view?usp=sharing" target="_blank">https://drive.google.com/a/jclarity.com/file/d/0B6IuyTuhCQTPUGpFcDA4bF8zbUk/view?usp=sharing</a>.</div><div><br></div><div>Regards,</div><div>Kirk</div><div><div class="h5"><div><br></div><div><br><div><blockquote type="cite"><div>On Dec 20, 2015, at 1:27 PM, Fabian Lange <<a href="mailto:fabian.lange@codecentric.de" target="_blank">fabian.lange@codecentric.de</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">Hi,</div><div dir="ltr">(originall posted on adoption-discuss)<br><div>since a while I have been recommending and using G1GC for JDK 8 applications.</div><div><br></div><div>This week I was looking at an application which should be the ideal candidate.</div><div>It was given 4GB ram, has a steady memory usage of about 1-2GB and during its work it generates only garbage. It reads data from sockets, deserializes it, manipulates it, serializes it and writes it out to sockets. It is processing 100k to 500k of such requests per second.</div><div><br></div><div>With the default G1 settings the machine was very loaded. The collection times were pretty long. It even ran out of memory a few times because the GC could not catch up.</div><div><br></div><div>When looking at the logs I was surprised to see extremely small eden/young sizes. The old gen was really big (like 3.5GB, but mostly empty) while G1 was churning on 300MB young.</div><div><br></div><div>I raised the question on <a href="https://groups.google.com/a/jclarity.com/d/msg/friends/hsZiz6HTm9M/MbuttBioCgAJ" target="_blank">https://groups.google.com/a/jclarity.com/d/msg/friends/hsZiz6HTm9M/MbuttBioCgAJ</a> where Charlie Hunt was so kind to explain the reasons behind the behaviour. It either did not make sense to me, or I did not understand the explanation. </div><div><br></div><div>What I did is what I always did regardless of the collector: I increased young space, knowing it contains mostly garbage.</div><div>The overall behaviour of the JVM was much improved by that.</div><div><br></div><div>I found it irritating, that according to Charlie, the main reason for the small eden is the Pause Time Limit. Because GC was not meeting its goal it reduced eden. While I observed better results doing the opposite.</div><div><br></div><div>I also enabled -XX:+<span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">ParallelRefProcEnabled.</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">Logs are available from the above discussion, but I can send them in separate mail if desired.</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><font face="Arial, Helvetica, sans-serif">As far as I can tell the ergonomics are not working for me, and the changes I need to do are counter intuitive. From other discussions I learned that quite many people observed better overall performance with raising the pause time restriction.</font></div><div><font face="Arial, Helvetica, sans-serif"><br></font></div><div><font face="Arial, Helvetica, sans-serif">Is there public information to why the current defaults are as they are? How would feedback on these defaults work?</font></div><div><br></div><div>Best regards,</div><div>Fabian</div></div>
</div><br></div>
</div></blockquote></div><br></div></div></div></div></blockquote></div><br></div></div>