Почему время разгрузки сборщика мусора G1 увеличивается со временем? - PullRequest
Новая
       41

Почему время разгрузки сборщика мусора G1 увеличивается со временем?

0 голосов
/ 24 октября 2018

Я испытываю странное поведение при использовании сборщика мусора G1 при запуске Glassfish под Solaris (SPARC) с JDK 8u172, время Unloading фазы Remark очень большое и увеличивается с течением времени.

Вот выдержка из журналов сразу после запуска сервера приложений:

2018-10-18T10: 08: 28.362 + 0200: 9528.430: [Замечание GC 2018-10-18T10: 08: 28.362 + 0200: 9528.430: [Завершить маркировку, 0.0012164 секунды] 2018-10-18T10: 08: 28.363 + 0200: 9528.431: [GC ref-proc, 0.1783250 секунд] 2018-10-18T10: 08:28.541 + 0200: 9528.609: [разгрузка, 1.4087725 с * ], 1.5954223 с] [время: пользователь = 10,79 сс = 0,04, реал = 1,60 с]

и через несколько дней:

2018-10-22T20: 24: 52,070 + 0200: 392111,556: [Замечание GC 2018-10-22T20: 24: 52,070 + 0200: 392111,556: [Завершить маркировку, 0,0010811 с] 2018-10-22T20: 24: 52,072 + 0200: 392111,557: [GC ref-proc, 0,1432306 с] 2018-10-22T20: 24: 52,215 + 0200: 392111,701: [Разгрузка, 5,4160564 с , 5,5672543 с] [Times: user = 41,16 sys = 0,06, real = 5,57 с]

Как видите, время Unloading выросло с 1,6 с до 5,6с.

Вот график Unloading раз с течением времени:

increasing unloading times over time

Как вы можете видеть, он увеличивается большеили менее линейно с течением времени.

Вот соответствующие флаги командной строки:

-XX: + AlwaysPreTouch -XX: GCLogFileSize = 10485760 -XX: InitialHeapSize = 8589934592 -XX: MaxHeapSize= 8589934592 -XX: MetaspaceSize = 536870912 -XX: NumberOfGCLogFiles = 5 -XX: + PrintGC -XX: + PrintGCDateStamps -XX: + PrintGCDetails -XX: + PrintGCTimeStamps -XX: + UnlockDiagnosticVlassOXOPSOXX: + UseG1GC -XX: + UseGCLogFileRotation -XX: + UseLargePages -XX: + UseLargePagesInMetaspace

Флаг -XX:+UseLargePagesInMetaspace был добавлен после прочтения этого сообщения в блоге , но, к сожалению, егоне решает проблему.Я также посмотрел этот другой пост в блоге и на этот вопрос , но, к сожалению, ни одно из предложенных решений, кажется, не применимо в этом случае.

Я могу 'Эта ошибка воспроизводится, когда сервер Glassfish работает под управлением других операционных систем / архитектур.

1 Ответ

0 голосов
/ 24 октября 2018

Это ошибка в JDK: JDK-8199406: падение производительности в Java JDK 1.8.0_162-b32 .

из описания ошибки и в этой теме обсуждения, эта ошибка:

  • - это регрессия, введенная в JDK 8u161, которая влияет на сбор мусора
  • характерна для Solaris: " имеются сообщения о падении производительности в Solaris SPARC64";" На x86 это действительно быстро. "
  • увеличивает время выгрузки класса: " Это регрессия, введенная в 8u161, которая увеличила время выгрузки класса со среднегоот 0,65 до 10 с для клиента."
  • исправлено в JDK 8u181 / 8u182.

Миграция в JDK 8u192 исправила ошибку, Unloading времена теперь намного меньше и постоянны:

2018-10-24T11: 57: 48.479 + 0200: 96295.786: [Замечание ГК 2018-10-24T11: 57: 48.480 + 0200: 96295.786: [Завершить маркировку, 0,0012370 секунд] 2018-10-24T11: 57: 48,481 + 0200: 96295,787: [GC ref-proc, 0,0960026 секунд] 2018-10-24T11: 57: 48,577 + 0200: 96295,883: [Разгрузка, 0,2760147с ], 0,3796341 с] [время: пользователь = 1,51 сис = 0,02, реальное = 0,38 с]

...