backport JEP 344-Abortable Mixed Collections for G1 to jdk11u
臧琳
zanglin5 at jd.com
Fri Mar 29 07:02:40 UTC 2019
Dear All
This is CCed from hotspot-gc-dev.
I am planing to port JEP344 back to JDK11u, it helps me to reduce the long pause MixedGC as discussed.
What is your opinion?
BRs,
Lin
>
>
> Dear Thomas and Charlie,
> Thanks for your suggestions.
> Let me describe more about my experiment. I am trying JDK11 on some sort of server node with huge heap at ~400GB. And it needs to keep the responsiveness so that long pause time of GC is not acceptable.
> And for some reason, if the server node paused for a long time (say 60s), the whole process will be killed and hence cause disaster.
> With JDK11 using G1, after some measurement I believe that keep MaxGCPauseMills at 200ms is reasonable and works well when there is no MixedGC - And also want to mention that the server node is super busy at allocation so there are usually 2~3 YGCs per minute.
> The problems comes with Mixed GC, I observed mainly two issues about it:
> a. There is super long pause time for MixedGC. Some times I found the whole process is killed because the MixedGC paused over 60s.
> b. There is back-to-back long MixedGCs, for examples, there can be 2~3 mixedGC within one minutes, and every one of them tooks ~30s. so the process get killed.
> For issue a, I think it seems that the collection set may be too large to be collected in low pause times. So I have tried to enlarge XX:G1MixedGCCountTarget to reduce the CSet for every MixedGC. But it seems this option could introduce more MixedGCs overall, which affected more or less of latency when normal MixedGCs happened. (Usually there is a batch of mixedGCs after concurrent marking, and seems the count of mixedGCs in a batch grows by enlarging XX:G1MixedGCCountTarget ), and this may cause issue b more severe.
> I also tried the option of -XX:G1HeapWastePercent, and it could more or less help reduce the MixedGC pause, but it shows if I enlarge it too much , more MixedGCs are going to happened.
>
> I come to consider that those options are good but they takes effect to all mixedGC’s, even for the cases that MixedGC pause time are acceptable.I tried to find a way to control the Cset by pause times, and I found the JEP344, after trying it in my case the long pause mixedGC is reduced by only introducing more low pause mixedGCs in that specific batch.
>
> PS. for the issue b mentioned, I think JEP344 may not help a lot. My data shown it comes from the updateRS&scanRS time, the tuning guide mentioned that so I will try it.
> And thanks for guiding me, I also cc this thread to jdk-updates-dev.
>
>
> BRs,
> Lin
>
>
>> 在 2019年3月29日,上午3:31,Thomas Schatzl <thomas.schatzl at oracle.com> 写道:
>>
>> Hi Lin,
>>
>> On Wed, 2019-03-27 at 10:51 +0000, 臧琳 wrote:
>>> Dear All,
>>> I have tried the JEP344 for a while and find it could help us to
>>> avoid the long Mixed GCs when the heap is large.
>>
>> It is great to hear that it helps you in your case.
>>
>> I assume you tried some tuning with the options presented in the
>> documentation at
>> https://docs.oracle.com/en/java/javase/12/gctuning/garbage-first-garbage-collector-tuning.html#GUID-D2B6ADCE-6766-4FF8-AA9D-B7F4F3D0F469
>> ?
>>
>> Note that in some cases this still might not result in as nice behavior
>> as with abortable mixed gc.
>>
>>> So I am planning to port it back to jdk11u as G1 is the default
>>> GC, do you think it is reasonable?
>>
>> I believe it is okay if it is useful, but it is best to ask the
>> maintainers of jdk11u directly in on the jdk-updates-dev mailing list.
>> As this would be a bit bigger change/backport, so there might be some
>> further concerns by the jdk11u maintainers.
>>
>> Code review seems to have to occur on the jdk-updates-dev mailing list
>> (https://openjdk.java.net/projects/jdk-updates/codereview.html) - maybe
>> cc hotspot-gc-dev though.
>>
>> Thanks,
>> Thomas
>>
>>
>
>
More information about the jdk-updates-dev
mailing list