英文地址:
http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstat.html
jstat是显示运行期jvm虚拟机行为统计的工具.
jstat的命令如下:
jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]
generalOption
假如你指定了一个一般的选项,那么不能指定其他的选项或参数.
-help 显示帮助信息
-version 显示版本信息(似乎用不了,报错”invalid argument count”)
-options 显示所有的统计选项列表.
output options
假如你没有指定一般的选项,那么你可以指定输出选项. 输出选项决定了jstat输出的内容和格式, 并也有一个单一的statOption(统计选项)加上任何其他的输出选项,如-h, -t, -J等. statOption必须出现在前面.
输出的格式如同一个table ,用空格隔开列信息. 第一行是每列的头信息描述. 使用-h选项可以指定头信息显示的频率. 也就是每几行显示一次头信息.
使用-t选项可以显示时间戳列,在输出的第一列显示. 时间戳列显示的时间是指该jvm实例从启动到现在的时间,单位是s(秒).
使用interval和count参数可以指定输出的频率和输出的次数.
-statOption
可以用jstat -options显示所有可用的statOption
class 显示class loader的行为统计
compiler 显示虚拟机即时的compiler行为统计
gc 显示堆的垃圾收集行为统计
gccapacity 显示jvm中各分区的容量和目前各分区占用的空间统计
gccause 显示垃圾收集的概要信息(和-gcutil一样),外加最近一次或当前的垃圾收集事件统计
gcnew 显示新生代的信息统计
gcnewcapacity 显示新生代容量信息统计
gcold 显示老生代和永久代信息统计
gcoldcapacity 显示老生代容量信息统计
gcpermcapacity 显示永久代容量信息统计
gcutil 显示垃圾收集的概要信息统计
printcompilation 显示虚拟机当前执行的方法的信息统计
-h
-t
-J
vmid格式
[protocol:][//]lvmid[@hostname][:port][/servername]
这个和jps中的格式类似,只不过在hostname前多了个进程号
最近在搞64位系统的升级,搞了一台放到正是环境的pool中,在原先的32位下,我们定义的heap size是1024m,其中permsize是96m,实用70m左右.同样的配置在64位jvm里,Perm Generation直接暴掉,于是扩大至128m,实用稳定在108m左右,这里的原因是64位系统下,object占用了更大的内存,可以用 -XX:+UseCompressedOops参数压缩(java6好像还不支持),但是我们没有使用.
经过前几天的运行,系统还算稳定(经过上午,下午两个网上流量高峰期).昨天发布后,我在晚上19点半左右enable这台测试机,早上到了公司,观察了一下运行情况.10点中左右发现jvm异常.
jstat -gcutil 22671 1000 1000
显示如下:
1
2
3
4
5
6
7
| S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 0.00 100.00 100.00 84.71 17079 392.748 586 960.447 1353.195
0.00 0.00 100.00 100.00 84.71 17079 392.748 587 962.212 1354.960
0.00 0.00 100.00 100.00 84.71 17079 392.748 587 962.212 1354.960
0.00 0.00 100.00 100.00 84.71 17079 392.748 588 963.992 1356.740
0.00 0.00 100.00 100.00 84.71 17079 392.748 588 963.992 1356.740
0.00 0.00 100.00 100.00 84.58 17079 392.748 589 965.907 1358.655 |
jmap 22671
显示如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
| Attaching to process ID 22671, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 10.0-b23
using thread-local object allocation.
Parallel GC with 8 thread(s)
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 1073741824 (1024.0MB)
NewSize = 268435456 (256.0MB)
MaxNewSize = 268435456 (256.0MB)
OldSize = 5439488 (5.1875MB)
NewRatio = 2
SurvivorRatio = 8
PermSize = 134217728 (128.0MB)
MaxPermSize = 134217728 (128.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 126615552 (120.75MB)
used = 126615552 (120.75MB)
free = 0 (0.0MB)
100.0% used
From Space:
capacity = 52494336 (50.0625MB)
used = 0 (0.0MB)
free = 52494336 (50.0625MB)
0.0% used
To Space:
capacity = 70909952 (67.625MB)
used = 0 (0.0MB)
free = 70909952 (67.625MB)
0.0% used
PS Old Generation
capacity = 805306368 (768.0MB)
used = 804698024 (767.4198379516602MB)
free = 608344 (0.5801620483398438MB)
99.92445806662242% used
PS Perm Generation
capacity = 134217728 (128.0MB)
used = 113520112 (108.26121520996094MB)
free = 20697616 (19.738784790039062MB)
84.57907438278198% used |
在上面显示的数据中,full gc频繁发生,占用了大量的资源
eden Space和Old Generation的heap多已经使用100%
于是dump jvm
jmap -dump:file=dump_run.hprof 22671
java6和64位下dump速度比在java5和32下快很多,瞬间完成.拷贝到本地,在eclipse里用mat插件(http://download.eclipse.org/technology/mat/0.7/update-site/)查看,立即找到问题,如图示:
昨日发布的一个变更设计有问题,出现了多份实例,没份实例占21m,共占用300m左右的内存.同样的情况在32位机器上表现的没有那么糟糕,似乎一切运行正常,看来64位的指针和对象占用heap单位比32下大很多.