本文目录一览:
- 1、Linux使用jstat命令查看jvm的GC情况
- 2、linux怎么监控 jvm内存 jstat
- 3、Linux系统监控要用到哪些命令
- 4、linux上如何安装jstatd服务
Linux使用jstat命令查看jvm的GC情况
Linux 使用jstat命令查看jvm的GC情况
命令格式
jstat命令命令格式:
jstat [Options] vmid[interval] [count]
参数说明:
Options,选项,我们一般使用 -gcutil 查看gc情况
vmid
,VM的进程号,即当前运行的java进程号
interval
,间隔时间,单位为秒或者毫秒
count
,打印次数,如果缺省则打印无数次
示例说明
示例
通常运行命令如下:
jstat -gc 12538 5000
即会每5秒一次显示进程号为12538的java进成的GC情况,
显示内容如下图:
结果说明
S0C:年轻代中第一个survivor(幸存区)的容量 (字节)
S1C
:年轻代中第二个survivor(幸存区)的容量 (字节)
S0U
:年轻代中第一个survivor(幸存区)目前已使用空间 (字节)
S1U
:年轻代中第二个survivor(幸存区)目前已使用空间 (字节)
EC
:年轻代中Eden(伊甸园)的容量 (字节)
EU
:年轻代中Eden(伊甸园)目前已使用空间 (字节)
OC
:Old代的容量 (字节)
OU
:Old代目前已使用空间 (字节)
PC
:Perm(持久代)的容量 (字节)
PU
:Perm(持久代)目前已使用空间 (字节)
YGC
:从应用程序启动到采样时年轻代中gc次数
YGCT
:从应用程序启动到采样时年轻代中gc所用时间(s)
FGC
:从应用程序启动到采样时old代(全gc)gc次数
FGCT
:从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT
:从应用程序启动到采样时gc用的总时间(s)
NGCMN
:年轻代(young)中初始化(最小)的大小 (字节)
NGCMX
:年轻代(young)的最大容量 (字节)
NGC
:年轻代(young)中当前的容量 (字节)
OGCMN
:old代中初始化(最小)的大小 (字节)
OGCMX
:old代的最大容量 (字节)
OGC
:old代当前新生成的容量 (字节)
PGCMN
:perm代中初始化(最小)的大小 (字节)
PGCMX
:perm代的最大容量 (字节)
PGC
:perm代当前新生成的容量 (字节)
S0
:年轻代中第一个survivor(幸存区)已使用的占当前容量百分比
S1
:年轻代中第二个survivor(幸存区)已使用的占当前容量百分比
E
:年轻代中Eden(伊甸园)已使用的占当前容量百分比
O
:old代已使用的占当前容量百分比
P
:perm代已使用的占当前容量百分比
S0CMX
:年轻代中第一个survivor(幸存区)的最大容量 (字节)
S1CMX
:年轻代中第二个survivor(幸存区)的最大容量 (字节)
ECMX
:年轻代中Eden(伊甸园)的最大容量 (字节)
DSS
:当前需要survivor(幸存区)的容量 (字节)(Eden区已满)
TT
: 持有次数限制
MTT
: 最大持有次数限制
linux怎么监控 jvm内存 jstat
jstat
可以观察到classloader,compiler,gc相关信息
-class:统计class loader行为信息
-compile:统计编译行为信息
-gc:统计jdk gc时heap信息
-gccapacity:统计不同的generations(不知道怎么翻译好,包括新生区,老年区,permanent区)相应的heap容量情况
-gccause:统计gc的情况,(同-gcutil)和引起gc的事件
-gcnew:统计gc时,新生代的情况
-gcnewcapacity:统计gc时,新生代heap容量
-gcold:统计gc时,老年区的情况
-gcoldcapacity:统计gc时,老年区heap容量
-gcpermcapacity:统计gc时,permanent区heap容量
-gcutil:统计gc时,heap情况
(详见)
Linux系统监控要用到哪些命令
记录一下自己常用的linux系统命令,方便以后查阅,发觉记忆越来越不行了
找到最耗CPU的java线程ps命令
命令:ps -mp pid -o THREAD,tid,time 或者 ps -Lfp pid
结果展示:
这个命令的作用,主要是可以获取到对应一个进程下的线程的一些信息。 比如你想分析一下一个java进程的一些运行瓶颈点,可以通过该命令找到所有当前Thread的占用CPU的时间,也就是这里的最后一列。
比如这里找到了一个TID : 30834 ,所占用的TIME时间最高。
通过 printf "%x\n" 30834 首先转化成16进制, 继续通过jstack命令dump出当前的jvm进程的堆栈信息。 通过Grep命令即可以查到对应16进制的线程id信息,很快就可以找到对应最耗CPU的代码快在哪。
简单的解释下,jstack下这一串线程信息内容:
"DboServiceProcessor-4-thread-295" daemon prio=10 tid=0x00002aab047a9800 nid=0x7d9b waiting on condition [0x0000000046f66000]
nid : 对应的linux操作系统下的tid,就是前面转化的16进制数字
tid: 这个应该是jvm的jmm内存规范中的唯一地址定位,如果你详细分析jvm的一些内存数据时用得上,我自己还没到那种程度,所以先放下
top命令
命令:top -Hp pid
结果显示:
和前面的效果一下,你可以实时的跟踪并获取指定进程中最耗cpu的线程。 再用前面的方法提取到对应的线程堆栈信息。
判断I/O瓶颈
mpstat命令
命令:mpstat -P ALL 1 1000
结果显示:
注意一下这里面的%iowait列,CPU等待I/O操作所花费的时间。这个值持续很高通常可能是I/O瓶颈所导致的。
通过这个参数可以比较直观的看出当前的I/O操作是否存在瓶颈
iostat命令
命令: iostat -m -x 1 1000
同样你可以观察对应的CPU中的%iowait数据,除此之外iostat还提供了一些更详细的I/O状态数据,比如比较重要的有:
avgqu-sz : The average queue length of the requests that were issued to the device. (磁盘队列的请求长度,正常的话2,3比较好。可以和cpu的load一样的理解)
await : The average time (in milliseconds) for I/O requests issued to the device to be served. (代表一个I/O操作从wait到完成的总时间)
svctm和%util都是代表处理该I/O请求花费的时间和CPU的时间比例。 判断是否瓶颈时,这两个参数不是主要的
r/s w/s 和 rMB/s wMB/s 都是代表当前系统处理的I/O的一些状态,前者是我们常说的tps,后者就是吞吐量。这也是评价一个系统的性能指标
pid命令
命令: pidstat -p pid -u -d -t -w -h 1 1000
结果显示:
相当实用的一个命令,可以基于当个进程分析对应的性能数据,包括CPU,I/O,IR , CS等,可以方便开发者更加精细化的观察系统的运行状态。不过pidstat貌似是在2.6内核的一些较新的版本才有,需要安装sysstat包。
ubuntu下,可以通过sudo apt-get install sysstat进行安装。
sar命令
命令:sar -x pid 1 1000
sar也可以指定对应的pid,关注固定的几个参数,没有pidstat那么强大。 看不到对应的I/O, IR等信息。
sar的功能可以覆盖mpstat , iostat的相关功能。
dstat命令
命令:dstat -y --tcp 1 1000
通过dstat --tcp可以比较方便的看到当前的tcp的各种状态,不需要每次netstat -nat去看
其他命令
netstat -natp : 查看对应的网络链接,关注下Recv-Q , Send-Q , State。
lsof -p pid : 查找对应pid的文件句柄
lsof -i : 80 : 查找对应端口被哪个进程占用
lsof /tmp/1.txt :查找对应文件被哪个进程占用
tcpdump / wireshark :抓包分析工具
jstat / jmap / jstack / jps 等一系列的java监控命令
最后
如果你想做一些性能调优的工作,一定要善于利用一些工具进行关注相应的状态。通过linux命令你可以比较方便的观测到CPU , I/O , network等一些比较外围的状态, 很多时候就已经可以解决大部分的问题。jvm内部的一些运行状态监控,得需要借助一些特有的工具进行细粒度的观测。
linux上如何安装jstatd服务
此命令是一个RMI Server应用程序,提供了对JVM的创建和结束监视,也为远程监视工具提供了一个可以attach的接口
options
-nr 当一个存在的RMI Registry没有找到时,不尝试创建一个内部的RMI Registry
-p port 端口号,默认为1099
-n rminame 默认为JStatRemoteHost;如果多个jstatd服务开始在同一台主机上,rminame唯一确定一个jstatd服务
-J jvm选项
jstatd
会报如下错误:
Could not create remote object access denied (java.util.PropertyPermission java.rmi.server.ignoreSubClasses write) java.security.AccessControlException: access denied (java.util.PropertyPermission java.rmi.server.ignoreSubClasses write) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.System.setProperty(System.java:727) at sun.tools.jstatd.Jstatd.main(Jstatd.java:122)
这是因为没有给jstatd指定安全策略
创建安全策略文件,并命名为jstatd.all.policy
grant codebase "file:${java.home}/../lib/tools.jar" {
permission java.security.AllPermission;
};
再次启动
C:\Program Files\Java\jdk1.6.0_16\binjstatd -J-Djava.security.policy=jstatd.all.policy
利用jps查看正在运行的java命令
jps
C:\Documents and Settings\lulujps
4892 Bootstrap
1296 Jstatd
4484 Jps
3332 org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
此时就可以使用jvisualvm.exe以远程的方式监控JVM相关信息了。
更多例子
(1)使用内部RMI Registry
jstatd -J-Djava.security.policy=all.policy (默认端口为1099)
(2)使用外部RMI Registry
a)使用默认值
rmiregistry
jstatd -J-Djava.security.policy=all.policy
b)使用2020端口
rmiregistry 2020
jstatd -J-Djava.security.policy=all.policy -p 2020
c)使用2020端口,使用rminame
rmiregistry 2020
jstatd -J-Djava.security.policy=all.policy -p 2020 -n AlternateJstatdServerName
(3)RMI Registry已经启动,不创建内部RMI Registry
jstatd -J-Djava.security.policy=all.policy -nr
(4)RMI日志能力
jstatd -J-Djava.security.policy=all.policy -J-Djava.rmi.server.logCalls=true