Java: увеличение размера YoungGen для улучшения производительности GC - PullRequest
Новая
       37

Java: увеличение размера YoungGen для улучшения производительности GC

2 голосов
/ 22 февраля 2012

Я читал следующую статью: http://java.sun.com/docs/hotspot/gc1.4.2/example.html и у меня возникают проблемы с пониманием следующих строк: 

Young generation size is too small

The young generation heap size in this first example is about 4 Mbytes with an overall heap size of about 32 Mbytes.

[GC [DefNew: 4032K->64K(4032K), 0.0429742 secs] 9350K->7748K(32704K), 0.0431096 secs]

[GC [DefNew: 4032K->64K(4032K), 0.0403446 secs] 11716K->10121K(32704K), 0.0404867 secs]

[GC [DefNew: 4032K->64K(4032K), 0.0443969 secs] 14089K->12562K(32704K), 0.0445251 secs]

This output seems reasonable from the point of view of the time spent in garbage collection but note that although the occupancy of the young generation is decreasing (e.g., in the first line from 4032 to 64k by 3968k) the occupancy of the entire heap is decreasing by considerably less (by 1602k from 9350k to 7748k). This indicates that only about 40% objects in the young generation were garbage and the rest survive the collection and are being promoted into the old generation.


Increasing the young generation size to increase the free space after the collection


The young generation heap size in this next run is increased to 8 Mbytes.


[GC [DefNew: 8128K->64K(8128K), 0.0453670 secs] 13000K->7427K(32704K), 0.0454906 secs]

[GC [DefNew: 8128K->64K(8128K), 0.0388632 secs] 15491K->9663K(32704K), 0.0390013 secs]

[GC [DefNew: 8128K->64K(8128K), 0.0388610 secs] 17727K->11829K(32704K), 0.0389919 secs]


With an 8 Mbyte size most of young generation is garbage at the time of the minor collection. In the first line the young generation heap decreases by 8064k from 8128k to 64k and the entire heap decreases by 5573k from 13000k to 7427k meaning about 68% of the young generation was garbage. As would be expected the size of the young generation does not change the amount of live objects that survive the minor collection (about 2.4M bytes in each case) but there are fewer minor collections and the cost of the collections in terms of the minor collection pause times are comparable (fractions of a second listed at the end of each line).

Мой вопрос заключается в том, как увеличение размера YoungGen помогает нам в этом случае.Общее количество объектов, которое приложение выделяет в YoungGen, будет постоянным.

Ответы [ 3 ]

6 голосов
/ 22 февраля 2012

Продвижение чего-либо из YoungGen стоит дорого, это вызывает:

  • это жить дольше, тратить память
  • будущих сборок мусора (каждая, пока он не умрет) будет дороже
  • это должно быть проигнорировано коллекциями YoungGen, и вам придется подождать, пока вы не исчерпаете более ценный ресурс и не запустите более дорогую коллекцию.

Увеличивая размер YoungGen, они гарантируют, что он собирает больше объектов, и, следовательно, не затрагивает ни одну из плохих точек выше. То есть объект быстро умирает и никому ничего не стоит, так что все быстрее?

Кроме того, есть намного более современная версия документа, который вы читаете, хотя, кажется, вам не хватает вашего примера: http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

1 голос
/ 22 февраля 2012

Стоимость молодой коллекции пропорциональна количеству сохраненных предметов.Чем больше молодая коллекция, тем больше вероятность того, что эти объекты больше не требуются, а это означает, что вы можете обнаружить, что стоимость молодой коллекции значительно не превышает определенного размера.

Для маленьких размеров молодого поколения это пропорционально, но для больших размеров не так много.Частота сбора падает пропорционально размеру.Вы можете достичь того, что его собирают реже одного раза в день.;)

YMMV в зависимости от поведения вашего приложения.

1 голос
/ 22 февраля 2012

Ответ лежит в самой статье.

Как и следовало ожидать, размер молодого поколения не меняет количество живых объектов, которые выживают в малой коллекции (около 2,4M байт в каждомслучай), но существует меньшее количество мелких коллекций, и стоимость коллекций с точки зрения времени приостановки второстепенных сборов сопоставима (доли секунды указаны в конце каждой строки).

ЭтоПрямое следствие увеличения YoungGen.

...