Understanding High Object Copy Times

[Thomas Schatzl]

Hi,


On Mon, 2017-05-01 at 14:40 -0700, nezih yigitbasi wrote:
> Charlie, Kirk, thanks for all the insights. We have actually fixed
> some sort of leak in the app and the situation definitely got
> better. 

  it seems that the VM is using too many threads: in one of the emails
in the thread you mentioned that the machine has 12 physical cores
available, but the logs indicate a value for the number of parallel gc
threads of 33 - which according to default heuristics indicate that the
VM detects a total of 48 cpu threads (24 cores?).

Maybe something went wrong with machine partitioning? Or that jdk8
version is too old to correctly handle cgroups? There have been some
patches to fix this some time ago, and I think b112 is too old to
contain these changes.

If you do not want to update, you need to set -XX:ParallelGCThreads
manually.

Which is what you might want to try anyway in cases of high object copy
in conjunction with termination time. Decreasing the number of parallel
gc threads to the number of cores available would be a good start.

As for reducing scan rs time during mixed gc, consider looking at the
appropriate section in the tuning guide for 9 (https://docs.oracle.com/
javase/9/gctuning/garbage-first-garbage-collector-tuning.htm#JSGCT-
GUID-70E3F150-B68E-4787-BBF1-F91315AC9AB9).

Otherwise, getting rid of the coarsenings in the output of
-XX:+G1SummarizeRSetStats by using -XX:G1RSetRegionEntries as mentioned
in that manual could help quite a bit.

To get back some of the additional memory usage,
-XX:G1RSetSparseRegionEntries could help. See http://mail.openjdk.java.
net/pipermail/hotspot-gc-use/2017-March/002640.html for some
explanation.

Thanks,
  Thomas