Jenkins JVM Tuning G1GC-备注卸载需要很长时间

Question

在我们的Jenkins Master计算机（Amazon AWS m3.large-> 2个vCPU，7.5GB RAM）上，我们正在运行G1垃圾收集器。当前的JVM（Java 8）参数为：

OpenJDK 64-Bit Server VM (25.171-b10) for linux-amd64 JRE (1.8.0_171-b10), built on Jun  5 2018 20:41:00 by "mockbuild" with gcc 4.8.5 20150623 (Red Hat 4.8.5-28)
Memory: 4k page, physical 7479432k(971040k free), swap 7290872k(5394708k free)
CommandLine flags: -XX:CICompilerCount=2 -XX:ConcGCThreads=1 -XX:+ExplicitGCInvokesConcurrent -XX:G1HeapRegionSize=2097152 -XX:GCLogFileSize=20971520 -XX:InitialHeapSize=4294967296 -XX:MarkStackSize=4194304 -XX:MaxHeapSize=4294967296 -XX:MaxNewSize=2575302656 -XX:MinHeapDeltaBytes=2097152 -XX:NumberOfGCLogFiles=5 -XX:+ParallelRefProcEnabled -XX:+PrintAdaptiveSizePolicy -XX:+PrintGC -XX:+PrintGCCause -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintReferenceGC -XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC -XX:+UseGCLogFileRotation -XX:+UseStringDeduplication 
{Heap before GC invocations=4895 (full 0):
 garbage-first heap   total 4194304K, used 2605010K [0x00000006c0000000, 0x00000006c0204000, 0x00000007c0000000)
  region size 2048K, 766 young (1568768K), 18 survivors (36864K)
 Metaspace       used 174305K, capacity 196623K, committed 197736K, reserved 1222656K
  class space    used 19614K, capacity 24634K, committed 24728K, reserved 1048576K

与晋升率相比，詹金斯人的分配率高：

对于某些GC阶段，GC日志显示30到40秒的非常长的暂停。特别是G1备注阶段需要很长时间：

2019-03-02T12:50:49.516+0100: 182886.605: [GC remark 
2019-03-02T12:50:49.516+0100: 182886.605:   [Finalize Marking, 0.0014687 secs] 
2019-03-02T12:50:49.518+0100: 182886.606:   [GC ref-proc
2019-03-02T12:50:49.518+0100: 182886.606:       [SoftReference, 125750 refs, 0.0469173 secs]
2019-03-02T12:50:49.565+0100: 182886.653:       [WeakReference, 13508 refs, 0.0094603 secs]
2019-03-02T12:50:49.574+0100: 182886.663:       [FinalReference, 123883 refs, 0.2796602 secs]
2019-03-02T12:50:49.854+0100: 182886.942:       [PhantomReference, 0 refs, 297 refs, 0.0008386 secs]
2019-03-02T12:50:49.855+0100: 182886.943:       [JNI Weak Reference, 0.0006230 secs],
                                            0.8821448 secs]
2019-03-02T12:50:50.400+0100: 182887.488: [Unloading, 41.7600667 secs],
                                          42.8461079 secs]
[Times: user=1.42 sys=0.59, real=42.84 secs]

如何进一步调查以确定此行为的根本原因？还有其他关于可能原因的想法吗？在这种情况下，卸载到底是什么？