Приложению требуется больше времени для обработки слабого задания JNI на этапе замечаний G1GC - PullRequest
0 голосов
/ 24 апреля 2020

Приложение работает с неожиданным поведением из-за этого длинного G C и пытается поднять время G C ниже 500 мс.

Фрагмент из журналов G C:

2020-03-17T16:50:04.505+0900: 1233.742: [GC remark 
2020-03-17T16:50:04.539+0900: 1233.776: [GC ref-proc
2020-03-17T16:50:04.539+0900: 1233.776: [SoftReference, 0 refs, 0.0096740 secs]
2020-03-17T16:50:04.549+0900: 1233.786: [WeakReference, 3643 refs, 0.0743530 secs]
2020-03-17T16:50:04.623+0900: 1233.860: [FinalReference, 89 refs, 0.0100470 secs]
2020-03-17T16:50:04.633+0900: 1233.870: [PhantomReference, 194 refs, 9 refs, 0.0168580 secs]
2020-03-17T16:50:04.650+0900: 1233.887: [JNI Weak Reference, 0.9726330 secs], 1.0839410 secs], 1.1263670 secs]

Приложение работает на Java 7 со следующими параметрами JVM:

CommandLine flags: -XX:+AggressiveOpts -XX:GCLogFileSize=52428800 -XX:+HeapDumpOnOutOfMemoryError -XX:InitialHeapSize=4294967296 
-XX:+ManagementServer -XX:MaxHeapSize=8589934592 -XX:MaxPermSize=805306368 -XX:MaxTenuringThreshold=15 -XX:NewRatio=5 
-XX:NumberOfGCLogFiles=30 -XX:+OptimizeStringConcat -XX:PermSize=268435456 -XX:+PrintGC -XX:+PrintGCDateStamps 
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintReferenceGC -XX:+UseCompressedOops 
-XX:+UseFastAccessorMethods -XX:+UseG1GC -XX:+UseGCLogFileRotation -XX:+UseStringCache 

Изменение таких параметров, как NewRatio, MaxTenuringThreshold, InitialHeapSize et c, приводит к изменению частоты таких длинных ГХ, но все же есть один или два.

Есть ли способ выяснить, что способствует длительному времени обработки слабой ссылки JNI?

...