повторная сборка мусора Java, хотя достаточно памяти Java - почему - PullRequest
7 голосов
/ 20 июля 2011

Наш процесс Java поглощает много ЦП, и журнал показывает, что он выполняет GC слишком часто, даже если используемая память составляет ~ 5 ГБ (взято из консоли JMX), а минимальная и максимальная память равна 10 ГБ.

нашаАргументы JVM: JVM_GC = "- подробный: gc -Xnoclassgc -XX: + PrintGCDetails -XX: + UseParNewGC -XX: NewSize = 3GB -XX: ParallelGCThreads = 8 -XX: MaxTenuringThreshold = 15 -XX * + UseConcMarkwe

и MinHeap = MaxHeap = 10 ГБ

Есть идеи, что может вызвать GC?и почему это происходит часто и слишком рано?Мы не можем подключить какой-либо инструмент профилирования в качестве производственного блока, кроме получения некоторых настроек через JMX ... Спасибо ..... GC log ....

@2011-07-20 02: 10: 46
[Полная ГХ (система) [CMS: 3333423K-> 4019122K (7340032K), 13,4979250 с] 4876606K-> 4019122K (10171200K), [CMS Perm: 21656K-> 21608K (21824K)], 13,4980930 с] [Время: пользователь = 12,99 сс = 0,50, реальное = 13,50 с]
[GC [1 CMS-начальная метка: 4019122K (7340032K)] 4041525K (10171200K), 0,0009110секунд] [Время: пользователь = 0,00 сис = 0,00, реальное = 0,00 с]
@ 2011-07-20 02: 11: 10
[CMS-concurrent-mark: 10,322 / 10,753с] [время: пользователь = 21,55 сс = 0,22, реальное = 10,75 с]
[CMS-concurrent-preclean: 0,035 / 0,036 с] [время: пользователь = 0,04 сс = 0,00, реальный = 0,04 с]
@ 2011-07-20 02: 11: 15
CMS: прервать предварительную очистку по времени [CMS-concurrent-abortable-preclean: 1,083 / 5,063 с] [Times: user = 1.08 sys = 0.00, реальное = 5,06 с]
[GC [занятость YG: 282204 K (2831168 K)] [Rescan (параллельный), 0,0402030 с] [слабая обработка ссылок, 0,0010550 с]
[1 CMS-примечание: 4019122K (7340032K)] 4301 326 К (10171200K), 0,0413630 с] [Times: user = 0,07 sys = 0,01, real = 0,04 с]
@ 2011-07-20 02: 11: 16
[CMS-одновременная развертка: 2,627 / 2,627 с] [время: пользователь = 2,63 сс = 0,00, реальное = 2,63 с]
[одновременный сброс CMS: 0,039 / 0,039 с] [время: пользователь = 0,04 сс = 0,00, реальный = 0,04 с]
@ 2011-07-20 02: 11: 20
[GC [1 CMS-начальная отметка: 4019034K (7340032K)] 4301238K (10171200K), 0,0308450 секунд] [Время: пользователь = 0,03 сис = 0,00, реальный = 0,03 с]
@ 2011-07-20 02: 11: 30
[CMS-concurrent-mark: 10,304 / 10,307 секунд] [Время: пользователь = 20,48 sys = 0,11, реальный = 10,31 секунд]
[CMS-concurrent-preclean: 0,018 / 0,019 с] [Время: пользователь = 0,02 сис = 0,00, реальное = 0,01 с]
@ 2011-07-20 02: 11: 35
CMS: отмена предварительной очистки из-завремя [CMS-concurrent-abortable-preclean: 1,043 / 5,048 с] Время: пользователь = 1,03 сс = 0,00, реальный = 5,05 с]
[GC [занятость YG: 282204 K(2831168 K)] [Повторное сканирование (параллельное), 0,0419560 с] [обработка слабых ссылок, 0,0010880 с]
[1 CMS-примечание: 4019034K (7340032K)]] 4301 238 К (10171200K), 0,0431480 с] [Times: user =0,07 sys = 0,01, реальное = 0,05 с]
@ 2011-07-20 02: 11: 38
[CMS-одновременная развертка: 2,622 / 2,622 с] [Times: user =2,63 сс = 0,00, реальный = 2,62 с]
[одновременный сброс CMS: 0,039 / 0,039 с] [время: пользователь = 0,04 сс = 0,00, реальный = 0,04 с]

Ответы [ 2 ]

4 голосов
/ 20 июля 2011

Попробуйте поиграть с флагами UseCMSInitiatingOccupancyOnly и CMSInitiatingOccupancyFraction.Использование этих флагов, инициирующих сбор CMS, будет запускаться в зависимости от занятости.Также, вероятно, есть смысл увеличить размер штатного поколения.

3 голосов
/ 20 июля 2011

Как насчет фрагментации памяти? Одновременная метка-и-развертка не сжимает память и со временем может стать очень фрагментированной - поэтому, хотя у вас достаточно общего пространства, вам может не хватить места для выделения нового объекта; и поэтому GC запускается.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...