UseConcMarkSweepGC против UseParallelGC

В настоящее время у меня проблемы с очень длительным временем сборки мусора. пожалуйста, смотрите следующее. Моя текущая настройка заключается в том, что я использую -Xms1g и -Xmx3g. мое приложение использует java 1.4.2. У меня не установлены флаги сборки мусора. Судя по всему, 3 ГБ недостаточно, и у меня действительно много объектов для сбора мусора.

вопрос:

я должен изменить свой алгоритм сбора мусора? что я должен использовать? лучше использовать -XX:+UseParallelGC or -XX:+UseConcMarkSweepGC

или я должен использовать эту комбинацию

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC

те, которые занимают память, в основном представляют собой данные отчетов, а не данные кэша. Кроме того, у машины 16 ГБ памяти, и я планирую увеличить кучу до 8 ГБ.

В чем разница между двумя вариантами, пока мне трудно понять. машина имеет несколько процессоров. Я могу выдерживать удары до 5 секунд, но от 30 до 70 секунд действительно тяжело.

Спасибо за помощь.

  Line 151493: [14/Jan/2012:11:47:48] WARNING ( 8710): CORE3283: stderr: [GC 1632936K->1020739K(2050552K), 1.2462436 secs]
    Line 157710: [14/Jan/2012:11:53:38] WARNING ( 8710): CORE3283: stderr: [GC 1670531K->1058755K(2050552K), 1.1555375 secs]
    Line 163840: [14/Jan/2012:12:00:42] WARNING ( 8710): CORE3283: stderr: [GC 1708547K->1097282K(2050552K), 1.1503118 secs]
    Line 169811: [14/Jan/2012:12:08:02] WARNING ( 8710): CORE3283: stderr: [GC 1747074K->1133764K(2050552K), 1.1017273 secs]
    Line 175879: [14/Jan/2012:12:14:18] WARNING ( 8710): CORE3283: stderr: [GC 1783556K->1173103K(2050552K), 1.2060946 secs]
    Line 176606: [14/Jan/2012:12:15:42] WARNING ( 8710): CORE3283: stderr: [Full GC 1265571K->1124875K(2050552K), 25.0670316 secs]
    Line 184755: [14/Jan/2012:12:25:53] WARNING ( 8710): CORE3283: stderr: [GC 2007435K->1176457K(2784880K), 1.2483770 secs]
    Line 193087: [14/Jan/2012:12:37:09] WARNING ( 8710): CORE3283: stderr: [GC 2059017K->1224285K(2784880K), 1.4739291 secs]
    Line 201377: [14/Jan/2012:12:51:08] WARNING ( 8710): CORE3283: stderr: [Full GC 2106845K->1215242K(2784880K), 30.4016208 secs]


xaa:1: [11/Oct/2011:16:00:28] WARNING (17125): CORE3283: stderr: [Full GC 3114936K->2985477K(3114944K), 53.0468651 secs] --> garbage collection occurring too often as noticed in the time. garbage being collected is quite low and if you would notice is quite close the the heap size. during the 53 seconds, this is equivalent to a pause.
xaa:2087: [11/Oct/2011:16:01:35] WARNING (17125): CORE3283: stderr: [Full GC 3114943K->2991338K(3114944K), 58.3776291 secs]
xaa:3897: [11/Oct/2011:16:02:33] WARNING (17125): CORE3283: stderr: [Full GC 3114940K->2997077K(3114944K), 55.3197974 secs]
xaa:5597: [11/Oct/2011:16:03:00] WARNING (17125): CORE3283: stderr: [Full GC[Unloading class sun.reflect.GeneratedConstructorAccessor119]
xaa:7936: [11/Oct/2011:16:04:36] WARNING (17125): CORE3283: stderr: [Full GC 3114938K->3004947K(3114944K), 55.5269911 secs]
xaa:9070: [11/Oct/2011:16:05:53] WARNING (17125): CORE3283: stderr: [Full GC 3114937K->3012793K(3114944K), 70.6993328 secs]

java performance garbage-collection g1gc concurrent-mark-sweep
person grassbl8d    schedule 25.01.2012    source источник
comment
Вот ссылка, которая может быть вам полезна oracle.com/technetwork /java/gc-tuning-5-138395.html. Коллекторы специфичны для версии 1.5, концепция параллельного и одновременного сканирования может быть такой же в версии 1.4.   -  person kosa    schedule 25.01.2012

Ответы (4)


arrow_upward
7
arrow_downward

Поскольку у вас чрезвычайно длинные паузы GC, не думаю, что изменение алгоритма GC поможет.

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

См. также:

person axtavt    schedule 25.01.2012
comment
да, это происходит только при создании отчетов. это объекты, поступающие из базы данных, и они имеют действительно большие значения. Мне было интересно, есть ли в любом случае, что я мог бы обойтись с этим. в сценарии 2 я думаю, что размера кучи действительно не хватает, поэтому мы планируем его увеличить, для сценария 1 куча все еще доступна. gc составляет от 25 до 30 секунд. - person grassbl8d; 25.01.2012
comment
извините за это, я не смог включить в него другой gc. включил его сейчас для первого сценария. - person grassbl8d; 25.01.2012

arrow_upward
4
arrow_downward

Ваша куча слишком мала. Пауза такая большая, потому что он занят повторным сканированием всей кучи, отчаянно ища что-нибудь для сбора.

Вам нужно сделать 1 или, возможно, больше из следующего;

  • найти и устранить утечку памяти
  • настроить приложение, чтобы использовать меньше памяти
  • настройка JVM использует большую кучу

Вы привязаны к 1.4.2 по какой-то причине? С тех пор реализации GC действительно продвинулись вперед, поэтому вам следует подумать об обновлении, если это возможно. Я понимаю, что это может быть нетривиальной задачей, но в любом случае стоит подумать.

person Matt    schedule 25.01.2012
comment
на самом деле это происходит только тогда, когда пользователи начинают генерировать большие отчеты, и мы действительно не можем их контролировать. отчеты действительно большие. в настоящее время мы находимся на сервере 1.4.2, процесс миграции идет, но нам нужно сделать то, что мы можем на данный момент. - person grassbl8d; 25.01.2012
comment
для сценария 1 у меня все еще есть доступная куча, поскольку моя максимальная куча составляет 3 ГБ, но сборка мусора все равно слишком длинная. - person grassbl8d; 25.01.2012
comment
Если генерация больших отчетов является частью нормальной работы, то ваша куча просто слишком мала. Однако вам нужно провести надлежащий бенчмаркинг, чтобы настроить это, и результат этих усилий будет, по крайней мере, частично избыточным, если вы перейдете на jvm java6 или java7. Вы не хотите делать одну и ту же работу дважды, если вы можете помочь ей. - person Matt; 26.01.2012
comment
для сценария 1 необходимо собрать больше данных о форме кучи. Флаги, на которые вам нужно обратить внимание: PrintTenuringDistribution, verbose:gc, -Xloggc:gc.log, PrintGCDetails и PrintGCTimeStamps. Когда у вас будет эта информация, люди смогут посоветовать разумные шаги по настройке, которые могут принести немедленную пользу. В конце концов, более 1 с для молодой коллекции огромно. - person Matt; 26.01.2012
comment
fwiw сборщик по умолчанию, iirc, в 1.4 был однопоточным последовательным сборщиком. Простое добавление -XX:+UseParallelGC почти наверняка даст вам существенное сокращение времени STW в молодой коллекции. Обратите внимание, что вам придется переключиться на CMS, чтобы улучшить штатный сборщик, поскольку, насколько я помню, в версии 1.4 нет paralleloldgc. Поэтому хорошей стратегией может быть гораздо большая куча и сборщик пропускной способности. Однако большая куча означает, что когда происходит постоянная коллекция, она может быть очень длинной. Также имейте в виду, что для работы CMS требуется куча большего размера, чем параллельный сборщик. - person Matt; 26.01.2012

arrow_upward
1
arrow_downward

Если у вас высокая выживаемость, ваша куча может быть слишком большой. Чем больше куча, тем дольше JVM может обходиться без GC, поэтому, как только она попадает, у нее появляется гораздо больше возможностей для перемещения.

person nilskp    schedule 05.03.2012

arrow_upward
1
arrow_downward

Шаг 1:

  1. Убедитесь, что вы установили достаточно памяти для вашего приложения.
  2. Убедитесь, что в вашем приложении нет утечек памяти. Eclipse Инструмент анализатора памяти или visualvm поможет вам определить утечки в вашем приложении.

Шаг 2:

Если у вас нет проблем с шагом 1 в отношении утечек памяти, обратитесь к документации Oracle страница с вариантами использования конкретного алгоритма сборки мусора в разделе "Сборщики мусора Java" и gctuning.

Поскольку вы решили настроить большие кучи (>= 8 ГБ), G1GC должен работать нормально для вас. Обратитесь к этому связанному с SE вопросу о точной настройке ключевых параметров:

Java 7 (JDK 7) сборка мусора и документация по G1

person Ravindra babu    schedule 09.12.2015