<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Dear Thomas,
<div class="">        Thanks for your suggestion! 
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>I will try to get those logs but that may take several days. </div>
<div class="">        And I will try ZGC and Shenandoah too.</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>I may ask help with more data in future :)</div>
<div class="">       </div>
<div class="">        Another possibility I can see is to enlarge the 32MB limitation of region size, after searching the code I think it may also possible to have (maybe 64MB) large regions for large heap with some code change. So that the cross region reference
 became possibly smaller. And seems enlarge the region to 64MB may a little memory overhead in the sparse PRT,  What do you think?</div>
<div class=""><br class="">
<div class="">BRs,</div>
<div class="">Lin<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">在 2019年3月29日,下午6:19,Thomas Schatzl <<a href="mailto:thomas.schatzl@oracle.com" class="">thomas.schatzl@oracle.com</a>> 写道:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Hi,<br class="">
<br class="">
On Fri, 2019-03-29 at 06:38 +0000, 臧琳 wrote:<br class="">
<blockquote type="cite" class="">Dear Thomas and Charlie,<br class="">
<br class="">
    Thanks for your suggestions. <br class="">
    Let me describe more about my experiment.  I am trying JDK11 on<br class="">
some sort of server node with huge heap at ~400GB. And it needs to<br class="">
keep the responsiveness so that long pause time  of GC is not<br class="">
acceptable. <br class="">
   And for some reason, if the server node paused for a long time<br class="">
(say 60s), the whole process will be killed and hence cause<br class="">
disaster. <br class="">
   With JDK11 using G1, after some measurement I believe that keep<br class="">
MaxGCPauseMills at 200ms is reasonable and works well when there is<br class="">
no MixedGC - And also want to mention that the server node is super<br class="">
busy at allocation so there are usually 2~3 YGCs per minute.<br class="">
<br class="">
It would be really interesting to get a log file with both a few of the<br class="">
"good" and the "bad" cases with<br class="">
-Xlog:gc=debug,gc+start=debug,gc+heap=debug,gc+phases=debug,gc+ergo+cse<br class="">
t=trace logging output (and showing other VM options).<br class="">
<br class="">
This would help us to gauge live set size and allocation rates.<br class="">
Depending on these, both Shenandoah and ZGC might be an alternative,<br class="">
and/or other tunings.<br class="">
<br class="">
I suspect that for example, with such a large heap you will get<br class="">
remembered set coarsenings as described in the "High Update RS and Scan<br class="">
RS Times" in the tuning guide (see also there for how to diagnose them,<br class="">
but please read the gotcha for diagnosing this in production - via jcmd<br class="">
you could just add that logging temporarily though). If you can see<br class="">
those, I would try "-XX:G1RSetRegionEntries=30000" to remove the<br class="">
coarsenings and "-XX:G1RSetSparseRegionEntries=256" to fix remembered<br class="">
set memory consumption; I kind of recommend doing the latter anyway.<br class="">
<br class="">
There are also ways to decrease minimum pause time by bounding young<br class="">
generation size a bit (-XX:+MaxNewSize), but without logs that's just<br class="">
too much guessing.<br class="">
<br class="">
<blockquote type="cite" class="">   The problems comes with Mixed GC, I observed mainly two issues<br class="">
about it:<br class="">
         a. There is super long pause time for MixedGC.  Some times<br class="">
I found the whole process is killed because the MixedGC paused over<br class="">
60s.<br class="">
         b. There is back-to-back long MixedGCs, for examples, there<br class="">
can be 2~3 mixedGC within one minutes, and every one of them tooks<br class="">
~30s. so the process get killed.<br class="">
  For issue a, I think it seems that the collection set may be too<br class="">
large to be collected in low pause times. So I have tried to enlarge<br class="">
XX:G1MixedGCCountTarget to reduce the CSet for  every MixedGC. But it<br class="">
seems this option could introduce more MixedGCs overall, which <br class="">
<br class="">
That's natural. During mixed phase G1 minimizes the young gen size (to<br class="">
allowed of course) which determines the frequency of collections. If<br class="">
you have a huge allocation rate, you burn through the available memory<br class="">
until next GC very quickly.<br class="">
<br class="">
They shouldn't take 30s though :) I suspect above remembered set<br class="">
coarsening to be the main cause here.<br class="">
<br class="">
<blockquote type="cite" class="">affected more or less of latency when normal MixedGCs happened.<br class="">
(Usually there is a batch of mixedGCs after concurrent marking, and<br class="">
seems the count of mixedGCs in a batch grows by enlarging<br class="">
XX:G1MixedGCCountTarget ), and this may cause issue b more severe.<br class="">
<br class="">
Do not set G1MixedGCCountTarget too high.<br class="">
<br class="">
<blockquote type="cite" class="">  I also tried the option of -XX:G1HeapWastePercent, and it could<br class="">
more or less help reduce the MixedGC pause, but it shows if I enlarge<br class="">
it too much , more MixedGCs are going to happened.<br class="">
<br class="">
That's natural too.<br class="">
<br class="">
The default settings for many of these options are geared for somewhat<br class="">
smaller applications as you may have noticed. We do not have many<br class="">
"real-world" applications of that size for developing better auto-<br class="">
tuning, apart from being a bit short in available time. Help in that<br class="">
area is always appreciated though :)<br class="">
<br class="">
<blockquote type="cite" class="">  I come to consider that those options are good but they takes<br class="">
effect to all mixedGC’s, even for the cases that MixedGC pause time<br class="">
are acceptable.I tried to find a way to control the Cset by pause<br class="">
times, and I found the JEP344, after trying it in my case the long<br class="">
pause mixedGC is reduced by only introducing more low pause mixedGCs<br class="">
in that specific batch. <br class="">
<br class="">
Within a given pause time there can only be so much object copying that<br class="">
can fit into. We are constantly trying to push these boundaries, e.g.<br class="">
from internal testing of a JDK-8213108 prototype you will likely be<br class="">
very positively surprised sometime in the future, but if your design is<br class="">
based on evacuation in distinct pauses, there is a point where the<br class="">
amount of data to be copied is just too large to fit a reasonable time;<br class="">
I do not know whether this is the case here.<br class="">
<br class="">
<blockquote type="cite" class="">  PS. for the issue b mentioned, I think JEP344 may not help a<br class="">
lot. My data shown it comes from the updateRS&scanRS time, the tuning<br class="">
guide mentioned that so I will try it.<br class="">
  And thanks for guiding me, I also cc this thread to  jdk-updates-<br class="">
dev.<br class="">
<br class="">
Thanks,<br class="">
 Thomas<br class="">
<br class="">
<br class="">
<br class="">