UseConcMarkSweepGC vs UseParallelGC

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

Вопрос:

Должен ли я изменить алгоритм сбора мусора? что я должен использовать? лучше использовать -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]

Ответ 1

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

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

См. также:

Настройка коллекции мусора с помощью 1.4.2 Java [tm] виртуальной машины

Ответ 2

Ваша куча слишком мала. Пауза настолько велика, что она многократно просматривает всю кучу, отчаянно ищущую все, что нужно собрать.

Вам нужно сделать 1 или, возможно, несколько из следующих:

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

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

Ответ 3

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

Ответ 4

Шаг 1:

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

Шаг 2:

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

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

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