java 1.6.0_38-b05 vm 20.13-b02 GC优化手记

转载 2015年07月07日 15:23:24

http://www.54chen.com/java-ee/jvm.html



基础:
业务代码
rose框架(底层是spring)
resin4
java 1.6.0_38-b05
centos

初始配置:
只修改了以下三个值
-Xmx5000M // max的heap的大小。
-Xms5000M // min的heap的大小,就是一初始给的大小,不够先GC,还不够再加,直到max。
-Xmn2000M //young区的大小,一般来讲:heap=Y+O,P是额外的值。Sun推荐Y=heap*(3/8)。

gc情况解读:
# jstat -gcutil 20538 1000 100
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 51.96 62.53 73.42 99.93 35830 1554.778 185 1089.488 2644.266
0.00 51.96 69.83 73.42 99.93 35830 1554.778 185 1089.488 2644.266
0.00 51.96 77.75 73.42 99.93 35830 1554.778 185 1089.488 2644.266
0.00 51.96 85.79 73.42 99.93 35830 1554.778 185 1089.488 2644.266
0.00 51.96 92.35 73.42 99.93 35830 1554.778 185 1089.488 2644.266

S0\S1是survivor区,就是没被gc掉的对象,在这两个survivor里来回导来导去,满足条件最后进行O区。
E是Eden区,E+S0+S1=Y。
从jstat的数据看,这个机器大概15s发生一次YGC,很长时间没有FGC了(超过1天以上),而且P区已经99.93%使用了。

各区内存情况解读:

#jmap -heap 20538
Attaching to process ID 20538, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 20.13-b02
using thread-local object allocation.
Parallel GC with 8 thread(s)
Heap Configuration:
MinHeapFreeRatio = 40 //如果连40%空闲都空不出来,就需要增加heap到xmx了。
MaxHeapFreeRatio = 70 //如果70%空闲了就别折腾了,减少去xms。
MaxHeapSize      = 5242880000 (5000.0MB) -Xmx
NewSize          = 2097152000 (2000.0MB)  // -Xmn
MaxNewSize       = 2097152000 (2000.0MB)
OldSize          = 5439488 (5.1875MB)  //old区的初始大小 此默认值在32位平台上是4M,在64位平台上是5M多。基本无用。
NewRatio         = 2  // Y/O=1/2  表示Y区要占三分之一
SurvivorRatio    = 8 // Y区里的S与E的比例:S/E = 2/8,Y区里十分之一当S区(因为有两个S)。
PermSize         = 21757952 (20.75MB)  //P区默认配置初始值
MaxPermSize      = 85983232 (82.0MB) //P区默认配置最大值   32位的服务器时是64M,64位服务器时是64×(0.3*64) =82.2M左右。
Heap Usage:
PS Young Generation
Eden Space:
capacity = 1966604288 (1875.5MB)
used     = 968355296 (923.4955749511719MB)
free     = 998248992 (952.0044250488281MB)
49.23996667294971% used
From Space:
capacity = 64880640 (61.875MB)
used     = 32440384 (30.93756103515625MB)
free     = 32440256 (30.93743896484375MB)
50.00009864267677% used
To Space:
capacity = 65273856 (62.25MB)
used     = 0 (0.0MB)
free     = 65273856 (62.25MB)
0.0% used
PS Old Generation
capacity = 3145728000 (3000.0MB)
used     = 2375317280 (2265.279083251953MB)
free     = 770410720 (734.7209167480469MB)
75.50930277506511% used
PS Perm Generation
capacity = 80805888 (77.0625MB)
used     = 80753328 (77.01237487792969MB)
free     = 52560 (0.0501251220703125MB)
99.93495523494525% used
P区虽然显示的99%used,但是与max相比还有剩余,在spring AOP众多,一次性启动的特点下,相比82M的max,才使用到77M,还有上扬的空间。实测FGC的发生也只是一天一次。

是否需要优化判定:

YGCT/YGC=40ms  且十几秒才一次,健康

FGCT/FGC=5s  但是一天也没几次,业务允许,一般健康可优化。未来可考虑优化为多次FGC减少FGCT的时长。

后续思考:
虽然FGC并不频繁,但因为xmx值比较大,导致了O区相对变大,同时FGC缓慢,考虑从两个方向:1.调整Y区大小,让YGC去到O区的数据更少,让FGC频率更加慢(有可能很难有变化)2.调整整体的大小,让FGC频繁一点点但更加快一点 3.调整FGC的算法,让速度快一点到1秒内来。

对照组结果后续有结论了再来续本文内容。

GC优化永远是最后一项任务。


相关文章推荐

B.FRIENDit壁虎忍者GC05电竞椅

B.FRIENDit壁虎忍者品牌电竞系列产品有很多,电竞椅,电竞键盘,电竞耳机,电竞鼠标等。今年八月,B.FRIENDit壁虎忍者又出了一款新的电竞椅GC05,就在这个月上市啦。这款B.FRIENDi...

《Java解惑》系列——02字符谜题——谜题18:字符串奶酪(new String(byte [] b))

知识点: 问题: 解决方法: 总结:

三星B309I固件GC14

  • 2017-03-10 01:17
  • 35.09MB
  • 下载

JVM(3)对象A和B循环引用,最后会不会不被GC回收?-------关于Java的GC机制

①首先说一下,GC里边在JVM当中是使用的ROOT算法,ROOT算法,什么称作为ROOT呢,就是说类的静态成员,静态成员就是static修饰的那种,是“根”的一个,根还包括方法中的成员变量,只有成员或...
  • kkgbn
  • kkgbn
  • 2015-03-31 23:49
  • 2593

DirectX 9.0c游戏开发手记之RPG编程自学日志之9: Drawing with DirectX Graphics (用DirectX图形绘图)(第4节)(B)

本文由哈利_蜘蛛侠原创,转载请注明出处!有问题请联系2024958085@qq.com           这一次我们继续来讲述Jim Adams老哥的RPG编程书籍第二版第二章的第4节:Gett...

wrar38b1sc

  • 2008-07-17 22:29
  • 1.20MB
  • 下载

wrar38b3

  • 2008-07-22 17:34
  • 1.18MB
  • 下载
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)