Java:增加YoungGen大小以提高GC性能
我正在阅读以下文章: 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 中分配的对象总数将是恒定的。
I was reading the following article: http://java.sun.com/docs/hotspot/gc1.4.2/example.html and have trouble understanding the following lines:
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).
My question is, how does increasing the size of YoungGen helps us in this case. The total number of objects that application allocates in YoungGen will be constant.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
从 YoungGen 中提升某些东西是昂贵的,它会导致:
通过增加 YoungGen 的大小,他们可以确保它收集更多的对象,从而不会遇到上述任何坏点。也就是说,该物体很快就会死亡,并且不会给任何人造成任何损失,所以一切都变得更快?
此外,您正在阅读的文档有一个更现代的版本,尽管它似乎缺少您的示例:
http://www.oracle.com/technetwork/java /javase/gc-tuning-6-140523.html
Promoting something out of the YoungGen is expensive, it causes:
By increasing the size of the YoungGen, they are ensuring that more of the objects are collected by it, and hence not hitting any of the bad points above. That is, the object dies quickly and doesn't cost anyone anything bad, so everything is faster?
Additionally, there's a much more modern version of the document you're reading, although it seems to lack your example:
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
答案就在文章本身。
这是增加 YoungGen 的直接结果。
The answer lies in the article itself.
This is a direct consequence of increasing the YoungGen.
年轻集合的成本与保留的对象数量成正比。年轻集合越大,不再需要这些对象的可能性就越大,这意味着您会发现年轻集合的成本在超过一定大小后不会增加太多。
对于较小的年轻一代来说,它是成比例的,但对于较大的规模来说,则没有那么大。收集频率随大小成比例下降。您可以达到每天收集不到一次的程度。 ;)
YMMV 取决于您的应用程序的行为方式。
The cost of a young collection is proportional to the number of objects retained. The larger the young collection the more likely that those objects are no longer required, meaning you can find that the cost of a young collection doesn't increase much beyond a certain size.
For small young gen sizes its proportional but for larger sizes not so much. The frequency of collection drops proportionally with size. You can reach the point that its collecting less than once per day. ;)
YMMV depending on how your application behaves.