关于大并发下,GC的问题

Diligence_ 发布于 2014/01/24 15:40
阅读 1K+
收藏 0
   关于GC这块之前没具体的去做过分析和优化,现在是想了解下, JVM的 Xmx 是 3个G ,初始也是这个数,采用的GC策略是 UseConcMarkSweepGC -XX:+UseParNewGC ,  如果并发量在10000左右,如果每个请求平均会有一个user对象,一个map,一个list, 平均多久发生一次GC算是正常,平均多久发生一次full GC 算是正常?
加载中
0
duty
duty
这没法估计,是需要根据你业务场景判断的,没有标准。一般来说几分钟一次fullgc是可以接受的。还要看full gc占用的时间
Diligence_
Diligence_
谢谢
duty
duty
这个gc日志很正常。耗时才40毫秒。10秒一次在高并发下是很正常的,你可以把精力放到其他点上去做优化了。
Diligence_
Diligence_
这个是一次gc的日志情况 GC 457348K->183564K(2063104K), 0.0408900 secs],1000并发的时候10秒就会有一次,这样是不是过于频繁?
0
duty
duty
时间越短越好,然后再看看每次回收率怎么样.正常的话,每次full gc应该回收绝大部分内存。
0
RainJ
RainJ
你设置的Xms也是3G么, 如果是的话要稍微好点,jvm不用扩展或者收缩内存.不过申请这么大的内存(默认配置新生代750M,老生代2.25G), full gc一下估计要stop好久(即使是minor GC也要等一会呢), 并且这样的话很多请求都会block住,并且导致连锁反应. 在单机io能够满足并发量的前提下,建议开多个sevlet服务器(内存充裕每个-Xms1024m -Xmx1024m)并做软件负载均衡.
duty
duty
确实cpu很好..
RainJ
RainJ
回复 @Diligence_ : Minor GC一般不耗太多时间的,因为Minor GC最多做一个Mark-Sweep 外加一个survivor 的一次copy不像FULL GC 的 Mark-Reorder
Diligence_
Diligence_
回复 @Quark : fullgc目前并不是很多,我只是觉得 m gc 多,不过听了楼上的意见 ,也觉得还好,另外G1还不是很稳定吧,太新了,不敢用
RainJ
RainJ
回复 @Quark : 如果你现在full gc 很频繁但是gc时间短(在不改变jvm对内存的前提下),你可以稍微将-XX:NewRatio 设置大点,反之你可以稍微设置小点(微调), 当然你也可以尝试其他的gc策略(譬如ParNew + CMS 或者如果支持G1的话也可以尝试一下)
RainJ
RainJ
回复 @Diligence_ : OldGen:YougGen = 3:1 已经是很好的配置的,当然视业务而定. 如果比例设置太高(即>3)那么单次FULL GC 会耗更多的时间,如果比例设的太低(例如2:1)一旦对象的生命周期稍长,那么FULL GC 会更加频繁。
下一页
0
13123123
13123123
你闲的蛋疼吗?   这个要看你code 写的怎么样 还有你对内存了解 指针的了解
0
RainJ
RainJ
 Xeon 4核 2.5GHz YoungGen + OldGen 1G, PermGen 256M, 平均FULL GC 1s, 坐等你贴8g 1s的
[Full GC (System) [PSYoungGen: 29751K->0K(297792K)] [PSOldGen: 382632K->372916K(699072K)] 412384K->372916K(996864K) [P
SPermGen: 85186K->85186K(170944K)], 1.3192100 secs] [Times: user=1.24 sys=0.08, real=1.32 secs]

RainJ
RainJ
回复 @breaking : 我只是很好奇8g内存FULL GC1s 需要什么样的CPU而已.
duty
duty
我第一个回答就已经说了,这个时间段长短是要看场景的,没有可比性好吧
0
Raynor1
Raynor1
所以解决这一个最好的办法就是。。。尽量少的让你的应用去触发FULL GC。。嗯。
Raynor1
Raynor1
@Quark 我说的是尽量少的。。。没有说避免。。
RainJ
RainJ
我觉得触发full gc是无可避免的,但是stop the world 的时间一定不能长,否则一旦请求block住了就会导致连锁反应
0
华兹格
华兹格
一般都是出了问题才去分析问题啊,还没有出问题,怎么知道设计的不合理,先跑一阵子再说,出现问题了再具体分析是什么造成了oom
Diligence_
Diligence_
只是想最大程度的避免问题出现。
0
专业打酱油
专业打酱油

历史经验告诉你:

full GC 大概 1G 1S,

8G 1S的真没见过,如果能行的话,估计分布式java要退出江湖了

建议楼主如果SERVER内存大的话,可以copy多份应用,每个应用份少点内存,

经验告诉你,4个应用,每个2G,比一个应用8G,要好很多。

另外GC收集器一般没有最好的,都是试出来的,要不也不会有G1。

你只要认为目前GC没问题,就不用优化,免得适得其反。


 

返回顶部
顶部