UseConcMarkSweepGC vs UseParallelGC - PullRequest
Новая
       26

UseConcMarkSweepGC vs UseParallelGC

27 голосов
/ 25 января 2012

У меня сейчас проблемы с очень долгим временем сбора мусора.пожалуйста, смотрите следующее.Моя текущая настройка заключается в том, что я использую -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]

Ответы [ 4 ]

7 голосов
/ 25 января 2012

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

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

См. Также:

4 голосов
/ 25 января 2012

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

Вам необходимо выполнить 1 или более из следующих действий:

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

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

1 голос
/ 09 декабря 2015

Шаг 1:

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

Шаг 2:

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

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

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

1 голос
/ 06 марта 2012

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

...