garbage collection issue - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Java - 爪哇娇娃

garbage collection issue

garbage collection issue# Java - 爪哇娇娃

o*a2008-07-23 07:07

1 楼

I set the -Xmax=12g. At initial launch, garbage collection happens when
young generation reaches around 3G, gc time takes around 0.5 seconds, the
interval between gc is 5minutes. After running a few days, gc happens much
more often than before, now every few seconds, there is a gc happening. The
good thing is that it took very short-- 0.05 seconds. I am just curious
about why JVM kick off gc that often.
Can anyone shed some light on it?
beginning:
97.788: [GC [PSYoungGen: 3036448K->643872K(33088

b*y2008-07-23 07:07

2 楼

No idea yet. What kind of tool you used for profiling the java GC process?
It might be your application has frequent memory allocation and deallocation
going on?

m*t2008-07-23 07:07

3 楼

The
If you are this concerned about gc, there is a whole sleu of
-XX GC tuning options to play with:
http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
For instance one thing you might want to look at is -XX:SurviverRatio
which lets you adjust how big the young gen according to your
app's memory usage pattern.

【在 o*******a 的大作中提到】

: I set the -Xmax=12g. At initial launch, garbage collection happens when
: young generation reaches around 3G, gc time takes around 0.5 seconds, the
: interval between gc is 5minutes. After running a few days, gc happens much
: more often than before, now every few seconds, there is a gc happening. The
: good thing is that it took very short-- 0.05 seconds. I am just curious
: about why JVM kick off gc that often.
: Can anyone shed some light on it?
: beginning:
: 97.788: [GC [PSYoungGen: 3036448K->643872K(33088

i*k2008-07-23 07:07

4 楼

12g 的heap太大了。不知道你的APP是什么。如果是需要支持很多用户的WEB，正确的方
法是考虑用cluster， horizontally scale up。
目前的JVM，对12G这么大的HEAP都会出现性能病态。你肯定是在用64位JVM。64位JVM本
身目前也普遍比32位JVM慢20 ～ 25%左右。多数厂商建议即使在64位OS上也要用32位
JVM。
如果用32位JVM，在3G左右还是频繁OLD GEN GC，那么你的APP应该是病态的，需要
PROFILE什么类的对象被频繁分配和GC，是否有大STRING对象被频繁分配（ String +
String 之类的code），是否有大块数据频繁被IO。针对这些情况，考虑用FLYWEIGHT一
类的设计模式，用StringBuffer，用cache strategy。下载一个免费试用的工具
YourKit，解决这类问题很有效。

The

【在 o*******a 的大作中提到】

t*e2008-07-23 07:07

5 楼

这个说明很棒,很多实用的信息.

【在 i****k 的大作中提到】

: 12g 的heap太大了。不知道你的APP是什么。如果是需要支持很多用户的WEB，正确的方
: 法是考虑用cluster， horizontally scale up。
: 目前的JVM，对12G这么大的HEAP都会出现性能病态。你肯定是在用64位JVM。64位JVM本
: 身目前也普遍比32位JVM慢20 ～ 25%左右。多数厂商建议即使在64位OS上也要用32位
: JVM。
: 如果用32位JVM，在3G左右还是频繁OLD GEN GC，那么你的APP应该是病态的，需要
: PROFILE什么类的对象被频繁分配和GC，是否有大STRING对象被频繁分配（ String +
: String 之类的code），是否有大块数据频繁被IO。针对这些情况，考虑用FLYWEIGHT一
: 类的设计模式，用StringBuffer，用cache strategy。下载一个免费试用的工具
: YourKit，解决这类问题很有效。