В каком случае сборка мусора java молодого поколения длится долго?

Question

вчера у нас был следующий вывод GC в журнале сервера одного сервера приложений JBoss:

51628.286: [GC 51628.288: [ParNew: 1843200K->204800K(1843200K), 21.3196040 secs]
5177730K->3743415K(7987200K), 21.3217870 secs]
[Times: user=1.38 sys=0.33, real=21.32 secs] 

Я понимаю вывод примерно так: молодое поколение имеет размер 1843200K.Размер до поколения был 1843200K, размер после 204800K.Сбор длился 21,3 секунды.

Обычно наши коллекции молодого поколения длятся <1 сек.При каких обстоятельствах коллекции yg сохраняются так долго? </p>

Наши параметры JVM:

-server 
-verbose:gc
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails 
-XX:NewRatio=3
-XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC 
-XX:+UseCMSCompactAtFullCollection 
-XX:CMSInitiatingOccupancyFraction=60 
-XX:MaxPermSize=256m 
-Xss512k 
-Xms8000m 
-Xmx8000m

java версия:

java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode)

Спасибо, Марсель

Answer 1

У нас был сервер tomcat, у которого были сборки мусора, которые продолжались ~ 2 минуты.В конце концов, мы нашли причину, мы выделили больше памяти для JVM через -Xmx, чем у нас было физической памяти в системе.Это вызывало разбиение на страницы во время сборки мусора, что убивает его.

Кроме того, у нас было несколько виртуальных машин, которые работали на одной физической машине.Убедитесь, что вы не выделили больше памяти всем виртуальным машинам, чем физической памяти на сервере.

Для получения дополнительной информации см. Настройка системы управления памятью, раздел Настройка размера кучи * 1006.* (мой акцент):

Параметры командной строки: -Xms: -Xmx:

Размер кучи влияет на скорость выделения, частоту сбора мусора и время сбора мусора.Небольшая куча быстро заполнится, и ее нужно будет собирать чаще.Он также подвержен большей фрагментации, что замедляет распределение объектов.Большая куча вносит небольшие накладные расходы во время сборки мусора. Куча, которая больше доступной физической памяти в системе, должна быть выгружена на диск, что приводит к длительному времени доступа или даже зависанию приложений, особенно во время сборки мусора .

Answer 2

Вы используете параллельный сборщик мусора (-XX:+UseConcMarkSweepGC), который работает в отдельном потоке.Из вывода «Таймс», который вы опубликовали, похоже, что сам сборщик мусора не работал долго.Я полагаю, что вашей системе не хватило процессорного времени для работы GC, поэтому GC потребовалось 20 с, чтобы получить 1 с процессорного времени.При использовании одновременного GC вы должны убедиться, что ваше приложение не потребляет все процессорное время.

В противном случае может произойти другая вещь: если параллельный коллектор не может освободить достаточно памяти и достигает определенного барьераон выполнит полный сборщик мусора, который заблокирует все другие потоки и потребует много времени.Этот Full GC имеет немного другой вывод (говорит Full GC вместо GC), поэтому я думаю, что это не ваша проблема здесь.

Answer 3

Я только что наткнулся на статью , в которой говорится, что использование огромных методов может вызвать длинные паузы GC (это последний раздел). Отрывок:

Когда метод компилируется, компиляторыгенерировать и сохранять информацию о том, где хранятся ссылки на объекты (Это помогает GC и называется oop map) Методы, размер которых превышает определенный размер, не будут JIT'ed в горячей точке.... Если метод не был обработан JIT, GC должен сам генерировать карты oop во время GC.... Большие методы означают большие абстрактные времена интерпретации для генерации oop-карт..... Кстати, огромный метод был примерно 2500 строк, поэтому я бы назвал его огромным.

(вставлен жирный текст)

Answer 4

Я полагаю, что это подсчет времени на настенных часах, поэтому, если другие процессы прервут ГХ и будут работать какое-то время, тогда об этом будет сообщено неправильно.

В молодом поколении не должно быть ничего, что заставляло бы сбор занимать много времени - стоимость GC пропорциональна количеству достижимых предметов, и ваши цифры показали, что только часть все еще была доступна.

Управление эталонной очередью и выполнение финализаторов могут занимать значительное количество времени, но не должны (??) учитываться для этого числа.

http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html содержит советы по настройке ГХ.