- 浏览: 540712 次
文章分类
最新评论
用jconsole来监控JVM
转自: http://blog.csdn.net/on_my_way20xx/article/details/8562055
当前测试服务器默认的启动脚本如下:
- <SPANstyle="FONT-SIZE:14px">#!/bin/bash
- exportCATALINA_HOME=/export/servers/tomcat6.0.33
- exportCATALINA_BASE=/export/home/tomcat/domains/server2
- ###JAVA
- exportJAVA_HOME=/export/servers/jdk1.6.0_25
- exportJAVA_BIN=/export/servers/jdk1.6.0_25/bin
- exportPATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/bin
- exportCLASSPATH=.:/lib/dt.jar:/lib/tools.jar
- exportJAVA_OPTS="-Djava.library.path=/usr/local/lib-server-Xms512m-Xmx1200m-XX:MaxPermSize=256m-Djava.awt.headless=true-Dsun
- .net.client.defaultConnectTimeout=60000-Dsun.net.client.defaultReadTimeout=60000-Djmagick.systemclassloader=no-Dnetworkaddress.ca
- che.ttl=300-Dsun.net.inetaddr.ttl=300"
- exportJAVA_HOMEJAVA_BINPATHCLASSPATHJAVA_OPTS
- $CATALINA_HOME/bin/startup.sh-config$CATALINA_BASE/conf/server.xml
- </SPAN>
#!/bin/bash
export CATALINA_HOME=/export/servers/tomcat6.0.33
export CATALINA_BASE=/export/home/tomcat/domains/server2
###JAVA
export JAVA_HOME=/export/servers/jdk1.6.0_25
export JAVA_BIN=/export/servers/jdk1.6.0_25/bin
export PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/bin
export CLASSPATH=.:/lib/dt.jar:/lib/tools.jar
export JAVA_OPTS="-Djava.library.path=/usr/local/lib -server -Xms512m -Xmx1200m -XX:MaxPermSize=256m -Djava.awt.headless=true -Dsun
.net.client.defaultConnectTimeout=60000 -Dsun.net.client.defaultReadTimeout=60000 -Djmagick.systemclassloader=no -Dnetworkaddress.ca
che.ttl=300 -Dsun.net.inetaddr.ttl=300"
export JAVA_HOME JAVA_BIN PATH CLASSPATH JAVA_OPTS
$CATALINA_HOME/bin/startup.sh -config $CATALINA_BASE/conf/server.xml
在 java_opts后面加上几个参数:
- <SPANstyle="FONT-SIZE:14px">-Dcom.sun.management.jmxremote-Djava.awt.headless=true
- -Dcom.sun.management.jmxremote.port=9008#端口号
- -Dcom.sun.management.jmxremote.ssl=false
- -Dcom.sun.management.jmxremote.authenticate=false
- -Djava.rmi.server.hostname=192.168.12.128"#IP地址</SPAN>
-Dcom.sun.management.jmxremote -Djava.awt.headless=true
-Dcom.sun.management.jmxremote.port=9008 #端口号
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=192.168.12.128 " #IP 地址
PS:如果一个服务有多个实例,请保持端口不同. 如第一个192.168.12.128:9008;第二个192.168.12.128:9010
然后使用jdk目录下jconsole启动,输入 类似 192.168.12.128:9008 即可连接(配置中的ip地址:端口号)
关于 jconsole的分析:
连接之后,我们要关注以下几个方面
1. 概述
如上图. 我们可以看到有两个垃圾收集器: ParNew 和 ConcurrentMarkSweep . 第一个是minor gc 第二个是full gc. 第一个经常启动,不会对性能造成坏的影响,第二个在old区很高的时候会启动,启动的时候会导致JVM暂停响应...
2. 内存 监控(堆内存) JCONSOLE最重要的作用之一就是监控内存是否有泄露,也就是内存释放是否正常.
如上图,5个柱图,由左到右分别是: CMS Old Gen、Par Eden Space、Par Survivor Space、Code Cache、CMS Perm Gen
在正常情况下,eden会占用较高,Survivor占用较低 ,old 占用很低; 如果发现old占用节节增高,那么很可能存在内存泄露。
另外补充一下 JVM GC的一些知识
如上图 JVM 将内存分为两大块 Young Generation 和 Old Generation
其中 Young Generation 又分为Eden Space和 Survivor Space(又分为From 和 To两块)
1.1、内存分配原则:
1、对象优先在EDEN分配,这里的大部分对象朝生夕灭,Minor GC主要清理该处
2、大对象(占内存大)、长期存活的对象(使用频繁)将直接进入老年代
Full GC的主要清理该处
3、适龄对象也可能进入老年代,判断是否适龄采用动态年龄判断方法.(动态对象年龄判断:
当Survivor空间的某个年龄a的所有对象大小总和大于Survivor空间的一半,年龄大于或等于a的对象就可以直接进入老年代)
1.2、JVM的GC机制
JVM有2个GC线程
第一个线程负责回收Heap的Young区 (minor GC)
第二个线程在Heap不足时(小于-Xms的值),遍历Heap,将Young 区升级为Older区 (FULL GC)。Older区的大小等于-Xmx减去-Xmn,所以不能将-Xms的值设的过大,因为第二个线程被迫运行会降低JVM的性能。
四、GC调优的小例子
例1:Heap size 设置
JVM 堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值,其初始空间(即-Xms)是物理内存的1/64,最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。
Heap size 的大小是Young Generation 和Tenured Generaion 之和。
当在JAVA_HOME下demo/jfc/SwingSet2/目录下执行下面的命令。
- java -jar -Xmn4m -Xms16m -Xmx16m SwingSet2.jar
- java-jar-Xmn4m-Xms16m-Xmx16mSwingSet2.jar
java -jar -Xmn4m -Xms16m -Xmx16m SwingSet2.jar
系统输出为:
- Exception in thread "Image Fetcher 0" java.lang.OutOfMemoryError: Java heap space
- Exception in thread "Image Fetcher 3" java.lang.OutOfMemoryError: Java heap space
- Exception in thread "Image Fetcher 1" java.lang.OutOfMemoryError: Java heap space
- Exception in thread "Image Fetcher 2" java.lang.OutOfMemoryError: Java heap space
- Exceptioninthread"ImageFetcher0"java.lang.OutOfMemoryError:Javaheapspace
- Exceptioninthread"ImageFetcher3"java.lang.OutOfMemoryError:Javaheapspace
- Exceptioninthread"ImageFetcher1"java.lang.OutOfMemoryError:Javaheapspace
- Exceptioninthread"ImageFetcher2"java.lang.OutOfMemoryError:Javaheapspace
Exception in thread "Image Fetcher 0" java.lang.OutOfMemoryError: Java heap space Exception in thread "Image Fetcher 3" java.lang.OutOfMemoryError: Java heap space Exception in thread "Image Fetcher 1" java.lang.OutOfMemoryError: Java heap space Exception in thread "Image Fetcher 2" java.lang.OutOfMemoryError: Java heap space
除了这些异常信息外,还会发现程序的响应速度变慢了。这说明Heap size 设置偏小,GC占用了更多的时间,而应用分配到的执行时间较少。
提示:在JVM中如果98%的时间是用于GC且可用的Heap size 不足2%的时候将抛出此异常信息。
将上面的命令换成以下命令执行则应用能够正常使用,且未抛出任何异常。
java -jar -Xmn4m -Xms16m -Xmx32m SwingSet2.jar
提示:Heap Size 最大不要超过可用物理内存的80%,一般的要将-Xms和-Xmx选项设置为相同,而-Xmn为1/4的-Xmx值。
例2:Young Generation(-Xmn)的设置
在本例中看一下Young Generation的设置不同将有什么现象发生。
假设将Young generation 的大小设置为4M ,即执行java -jar -verbose:gc -Xmn4m -Xms32m -Xmx32m -XX:+PrintGCDetails SwingSet2.jar,
屏幕输出如下(节选)
- [GC [DefNew: 3968K->64K(4032K), 0.0923407 secs] 3968K->2025K(32704K), 0.0931870 secs]
- [GC [DefNew: 4021K->64K(4032K), 0.0356847 secs] 5983K->2347K(32704K), 0.0365441 secs]
- [GC [DefNew: 3995K->39K(4032K), 0.0090603 secs] 6279K->2372K(32704K), 0.0093377 secs]
- [GC[DefNew:3968K->64K(4032K),0.0923407secs]3968K->2025K(32704K),0.0931870secs]
- [GC[DefNew:4021K->64K(4032K),0.0356847secs]5983K->2347K(32704K),0.0365441secs]
- [GC[DefNew:3995K->39K(4032K),0.0090603secs]6279K->2372K(32704K),0.0093377secs]
[GC [DefNew: 3968K->64K(4032K), 0.0923407 secs] 3968K->2025K(32704K), 0.0931870 secs] [GC [DefNew: 4021K->64K(4032K), 0.0356847 secs] 5983K->2347K(32704K), 0.0365441 secs] [GC [DefNew: 3995K->39K(4032K), 0.0090603 secs] 6279K->2372K(32704K), 0.0093377 secs]
将程序体制并将Young Generation的大小设置为8M,即执行
- java -jar -verbose:gc -Xmn8m -Xms32m -Xmx32m -XX:+PrintGCDetails SwingSet2.jar
- java-jar-verbose:gc-Xmn8m-Xms32m-Xmx32m-XX:+PrintGCDetailsSwingSet2.jar
java -jar -verbose:gc -Xmn8m -Xms32m -Xmx32m -XX:+PrintGCDetails SwingSet2.jar
屏幕输出如下(节选)
- [GC [DefNew: 7808K->192K(8000K), 0.1016784 secs] 7808K->2357K(32576K), 0.1022834 secs]
- [GC [DefNew: 8000K->70K(8000K), 0.0149659 secs] 10165K->2413K(32576K), 0.0152557 secs]
- [GC [DefNew: 7853K->59K(8000K), 0.0069122 secs] 10196K->2403K(32576K), 0.0071843 secs]
- [GC [DefNew: 7867K->171K(8000K), 0.0075745 secs] 10211K->2681K(32576K), 0.0078376 secs]
- [GC [DefNew: 7970K->192K(8000K), 0.0201353 secs] 10480K->2923K(32576K), 0.0206867 secs]
- [GC [DefNew: 7979K->30K(8000K), 0.1787079 secs] 10735K->4824K(32576K), 0.1790065 secs]
- [GC[DefNew:7808K->192K(8000K),0.1016784secs]7808K->2357K(32576K),0.1022834secs]
- [GC[DefNew:8000K->70K(8000K),0.0149659secs]10165K->2413K(32576K),0.0152557secs]
- [GC[DefNew:7853K->59K(8000K),0.0069122secs]10196K->2403K(32576K),0.0071843secs]
- [GC[DefNew:7867K->171K(8000K),0.0075745secs]10211K->2681K(32576K),0.0078376secs]
- [GC[DefNew:7970K->192K(8000K),0.0201353secs]10480K->2923K(32576K),0.0206867secs]
- [GC[DefNew:7979K->30K(8000K),0.1787079secs]10735K->4824K(32576K),0.1790065secs]
[GC [DefNew: 7808K->192K(8000K), 0.1016784 secs] 7808K->2357K(32576K), 0.1022834 secs] [GC [DefNew: 8000K->70K(8000K), 0.0149659 secs] 10165K->2413K(32576K), 0.0152557 secs] [GC [DefNew: 7853K->59K(8000K), 0.0069122 secs] 10196K->2403K(32576K), 0.0071843 secs] [GC [DefNew: 7867K->171K(8000K), 0.0075745 secs] 10211K->2681K(32576K), 0.0078376 secs] [GC [DefNew: 7970K->192K(8000K), 0.0201353 secs] 10480K->2923K(32576K), 0.0206867 secs] [GC [DefNew: 7979K->30K(8000K), 0.1787079 secs] 10735K->4824K(32576K), 0.1790065 secs]
那么根据GC输出的信息(这里取第一行)做一下Minor收集的比较。可以看出两次的Minor收集分别在Young generation中找回3904K(3968K->64K)和7616K(7808K->192K)而对于整个jvm则找回 1943K(3968K->2025)和5451K(7808K->2357K)。第一种情况下Minor收集了大约50%(1943/3904)的对象,而另外的50%的对象则被移到了tenured generation。在第二中情况下Minor收集了大约72%的对象,只有不到30%的对象被移到了Tenured
Generation.这个例子说明此应用在的Young generation 设置为4m时显的偏小。
提示:一般的Young Generation的大小是整个Heap size的1/4。Young generation的minor收集率应一般在70%以上。当然在实际的应用中需要根据具体情况进行调整。
例3:Young Generation对应用响应的影响
还是使用-Xmn4m 和-Xmn8m进行比较,先执行下面的命令
- java -jar -verbose:gc -Xmn4m -Xms32m -Xmx32m -XX:+PrintGCDetails -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime SwingSet2.jar
- java-jar-verbose:gc-Xmn4m-Xms32m-Xmx32m-XX:+PrintGCDetails-XX:+PrintGCApplicationConcurrentTime-XX:+PrintGCApplicationStoppedTimeSwingSet2.jar
java -jar -verbose:gc -Xmn4m -Xms32m -Xmx32m -XX:+PrintGCDetails -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime SwingSet2.jar
屏幕输出如下(节选)
- Application time: 0.5114944 seconds
- [GC [DefNew: 3968K->64K(4032K), 0.0823952 secs] 3968K->2023K(32704K), 0.0827626 secs]
- Total time for which application threads were stopped: 0.0839428 seconds
- Application time: 0.9871271 seconds
- [GC [DefNew: 4020K->64K(4032K), 0.0412448 secs] 5979K->2374K(32704K), 0.0415248 secs]
- Total time for which application threads were stopped: 0.0464380 seconds
- Applicationtime:0.5114944seconds
- [GC[DefNew:3968K->64K(4032K),0.0823952secs]3968K->2023K(32704K),0.0827626secs]
- Totaltimeforwhichapplicationthreadswerestopped:0.0839428seconds
- Applicationtime:0.9871271seconds
- [GC[DefNew:4020K->64K(4032K),0.0412448secs]5979K->2374K(32704K),0.0415248secs]
- Totaltimeforwhichapplicationthreadswerestopped:0.0464380seconds
Application time: 0.5114944 seconds [GC [DefNew: 3968K->64K(4032K), 0.0823952 secs] 3968K->2023K(32704K), 0.0827626 secs] Total time for which application threads were stopped: 0.0839428 seconds Application time: 0.9871271 seconds [GC [DefNew: 4020K->64K(4032K), 0.0412448 secs] 5979K->2374K(32704K), 0.0415248 secs] Total time for which application threads were stopped: 0.0464380 seconds
Young Generation 的Minor收集占用的时间可以计算如下:
应用线程被中断的总时常/(应用执行总时?L+应用线程被中断的总时常),那么在本例中垃圾收集占用的时?L约为系统的5%~14%。那么当垃圾收集占用的时间的比例越大的时候,系统的响应将越慢。
提示:对于互联网应用系统的响应稍微慢一些,用户是可以接受的,但是对于GUI类型的应用响应速度慢将会给用户带来非常不好的体验。
例4:如何决定Tenured Generation 的大小
分别以-Xmn8m -Xmx32m和-Xmn8m -Xmx64m进行对比,先执行
- java -verbose:gc -Xmn8m -Xmx32m-XX:+PririntGCDetails -XX:+PrintGCTimeStamps java类
- java-verbose:gc-Xmn8m-Xmx32m-XX:+PririntGCDetails-XX:+PrintGCTimeStampsjava类
java -verbose:gc -Xmn8m -Xmx32m-XX:+PririntGCDetails -XX:+PrintGCTimeStamps java类
命令行将提示(只提取了Major收集)
- 111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs]111.042: [Tenured: 18154K->2311K(24576K), 0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs]
- 122.463: [GC 122.463: [DefNew: 8128K->8128K(8128K), 0.0000560 secs]122.463: [Tenured: 18630K->2366K(24576K), 0.1322560 secs] 26758K->2366K(32704K), 0.1325284 secs]
- 133.896: [GC 133.897: [DefNew: 8128K->8128K(8128K), 0.0000443 secs]133.897: [Tenured: 18240K->2573K(24576K), 0.1340199 secs] 26368K->2573K(32704K), 0.1343218 secs]
- 144.112: [GC 144.112: [DefNew: 8128K->8128K(8128K), 0.0000544 secs]144.112: [Tenured: 16564K->2304K(24576K), 0.1246831 secs] 24692K->2304K(32704K), 0.1249602 secs]
- 111.042:[GC111.042:[DefNew:8128K->8128K(8128K),0.0000505secs]111.042:[Tenured:18154K->2311K(24576K),0.1290354secs]26282K->2311K(32704K),0.1293306secs]
- 122.463:[GC122.463:[DefNew:8128K->8128K(8128K),0.0000560secs]122.463:[Tenured:18630K->2366K(24576K),0.1322560secs]26758K->2366K(32704K),0.1325284secs]
- 133.896:[GC133.897:[DefNew:8128K->8128K(8128K),0.0000443secs]133.897:[Tenured:18240K->2573K(24576K),0.1340199secs]26368K->2573K(32704K),0.1343218secs]
- 144.112:[GC144.112:[DefNew:8128K->8128K(8128K),0.0000544secs]144.112:[Tenured:16564K->2304K(24576K),0.1246831secs]24692K->2304K(32704K),0.1249602secs]
111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs]111.042: [Tenured: 18154K->2311K(24576K), 0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs] 122.463: [GC 122.463: [DefNew: 8128K->8128K(8128K), 0.0000560 secs]122.463: [Tenured: 18630K->2366K(24576K), 0.1322560 secs] 26758K->2366K(32704K), 0.1325284 secs] 133.896: [GC 133.897: [DefNew: 8128K->8128K(8128K), 0.0000443 secs]133.897: [Tenured: 18240K->2573K(24576K), 0.1340199 secs] 26368K->2573K(32704K), 0.1343218 secs] 144.112: [GC 144.112: [DefNew: 8128K->8128K(8128K), 0.0000544 secs]144.112: [Tenured: 16564K->2304K(24576K), 0.1246831 secs] 24692K->2304K(32704K), 0.1249602 secs]
再执行
- java -verbose:gc -Xmn8m -Xmx64m-XX:+PririntGCDetails -XX:+PrintGCTimeStamps java类
- java-verbose:gc-Xmn8m-Xmx64m-XX:+PririntGCDetails-XX:+PrintGCTimeStampsjava类
java -verbose:gc -Xmn8m -Xmx64m-XX:+PririntGCDetails -XX:+PrintGCTimeStamps java类
命令行将提示(只提取了Major收集)
- 90.597: [GC 90.597: [DefNew: 8128K->8128K(8128K), 0.0000542 secs]90.597: [Tenured: 49841K->5141K(57344K), 0.2129882 secs] 57969K->5141K(65472K), 0.2133274 secs]
- 120.899: [GC 120.899: [DefNew: 8128K->8128K(8128K), 0.0000550 secs]120.899: [Tenured: 50384K->2430K(57344K), 0.2216590 secs] 58512K->2430K(65472K), 0.2219384 secs]
- 153.968: [GC 153.968: [DefNew: 8128K->8128K(8128K), 0.0000511 secs]153.968: [Tenured: 51164K->2309K(57344K), 0.2193906 secs] 59292K->2309K(65472K), 0.2196372 secs]
- 90.597:[GC90.597:[DefNew:8128K->8128K(8128K),0.0000542secs]90.597:[Tenured:49841K->5141K(57344K),0.2129882secs]57969K->5141K(65472K),0.2133274secs]
- 120.899:[GC120.899:[DefNew:8128K->8128K(8128K),0.0000550secs]120.899:[Tenured:50384K->2430K(57344K),0.2216590secs]58512K->2430K(65472K),0.2219384secs]
- 153.968:[GC153.968:[DefNew:8128K->8128K(8128K),0.0000511secs]153.968:[Tenured:51164K->2309K(57344K),0.2193906secs]59292K->2309K(65472K),0.2196372secs]
90.597: [GC 90.597: [DefNew: 8128K->8128K(8128K), 0.0000542 secs]90.597: [Tenured: 49841K->5141K(57344K), 0.2129882 secs] 57969K->5141K(65472K), 0.2133274 secs] 120.899: [GC 120.899: [DefNew: 8128K->8128K(8128K), 0.0000550 secs]120.899: [Tenured: 50384K->2430K(57344K), 0.2216590 secs] 58512K->2430K(65472K), 0.2219384 secs] 153.968: [GC 153.968: [DefNew: 8128K->8128K(8128K), 0.0000511 secs]153.968: [Tenured: 51164K->2309K(57344K), 0.2193906 secs] 59292K->2309K(65472K), 0.2196372 secs]
可以看出在Heap size 为32m的时候系统等候时间约为0.13秒左右,而设置为64m的时候等候时间则增大到0.22秒左右了。但是在32m的时候系统的Major收集间隔为 10秒左右,而Heap size 增加到64m的时候为30秒。那么应用在运行的时候是选择32m还是64m呢?如果应用是web类型(即要求有大的吞吐量)的应用则使用64m(即 heapsize大一些)的比较好。对于要求实时响应要求较高的场合(例如GUI型的应用)则使用32m比较好一些。
注意:
1。因为在JVM5运行时已经对Heap-size进行了优化,所以在能确定java应用运行时不会超过默认的Heap size的情况下建议不要对这些值进行修改。
2。 Heap size的 -Xms -Xmn 设置不要超出物理内存的大小。否则会提示“Error occurred during initialization of VM Could not reserve enough space for object heap”。
例5:如何缩短minor收集的时间
下面比较一下采用-XX:+UseParNewGC选项和不采用它的时候的minor收集将有什么不同。先执行
- java -jar -server -verbose:gc -Xmn8m -Xms32m -Xmx32m SwingSet2.jar
- java-jar-server-verbose:gc-Xmn8m-Xms32m-Xmx32mSwingSet2.jar
java -jar -server -verbose:gc -Xmn8m -Xms32m -Xmx32m SwingSet2.jar
系统将输出如下信息(片段〕
- [GC 7807K->2641K(32576K), 0.0676654 secs]
- [GC 10436K->3108K(32576K), 0.0245328 secs]
- [GC 10913K->3176K(32576K), 0.0072865 secs]
- [GC 10905K->4097K(32576K), 0.0223928 secs]
- [GC7807K->2641K(32576K),0.0676654secs]
- [GC10436K->3108K(32576K),0.0245328secs]
- [GC10913K->3176K(32576K),0.0072865secs]
- [GC10905K->4097K(32576K),0.0223928secs]
[GC 7807K->2641K(32576K), 0.0676654 secs] [GC 10436K->3108K(32576K), 0.0245328 secs] [GC 10913K->3176K(32576K), 0.0072865 secs] [GC 10905K->4097K(32576K), 0.0223928 secs]
之后再执行
- java -jar -server -verbose:gc -XX:+UseParNewGC -Xmn8m -Xms32m -Xmx32m SwingSet2.jar
- java-jar-server-verbose:gc-XX:+UseParNewGC-Xmn8m-Xms32m-Xmx32mSwingSet2.jar
java -jar -server -verbose:gc -XX:+UseParNewGC -Xmn8m -Xms32m -Xmx32m SwingSet2.jar
系统将输出如下信息(片段〕
- [ParNew 7808K->2656K(32576K), 0.0447687 secs]
- [ParNew 10441K->3143K(32576K), 0.0179422 secs]
- [ParNew 10951K->3177K(32576K), 0.0031914 secs]
- [ParNew 10985K->3867K(32576K), 0.0154991 secs]
- [ParNew7808K->2656K(32576K),0.0447687secs]
- [ParNew10441K->3143K(32576K),0.0179422secs]
- [ParNew10951K->3177K(32576K),0.0031914secs]
- [ParNew10985K->3867K(32576K),0.0154991secs]
[ParNew 7808K->2656K(32576K), 0.0447687 secs] [ParNew 10441K->3143K(32576K), 0.0179422 secs] [ParNew 10951K->3177K(32576K), 0.0031914 secs] [ParNew 10985K->3867K(32576K), 0.0154991 secs]
很显然使用了-XX:+UseParNewGC选项的minor收集的时间要比不使用的时候优。
例6:如何缩短major收集的时间
下面比较一下采用-XX:+UseConcMarkSweepGC选项和不采用它的时候的major收集将有什么不同。先执行
- java -jar -verbose:gc -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx256m SwingSet2.jar
- java-jar-verbose:gc-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-Xmn64m-Xms256m-Xmx256mSwingSet2.jar
java -jar -verbose:gc -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx256m SwingSet2.jar
系统将输出如下信息(片段〕
- [Full GC 22972K->18690K(262080K), 0.2326676 secs]
- [Full GC 18690K->18690K(262080K), 0.1701866 secs
- [FullGC22972K->18690K(262080K),0.2326676secs]
- [FullGC18690K->18690K(262080K),0.1701866secs
[Full GC 22972K->18690K(262080K), 0.2326676 secs] [Full GC 18690K->18690K(262080K), 0.1701866 secs
之后再执行
- java -jar -verbose:gc -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx256m SwingSet2.jar
- java-jar-verbose:gc-XX:+UseParNewGC-Xmn64m-Xms256m-Xmx256mSwingSet2.jar
java -jar -verbose:gc -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx256m SwingSet2.jar
系统将输出如下信息(片段〕
- [Full GC 56048K->18869K(260224K), 0.3104852 secs]
- [FullGC56048K->18869K(260224K),0.3104852secs]
[Full GC 56048K->18869K(260224K), 0.3104852 secs]
提示:此选项在Heap Size 比较大而且Major收集时间较长的情况下使用更合适。
例7:关于-server选项
在JVM中将运行中的类认定为server-class的时候使用此选项。SUN 的Hot Spot JVM5 如果判断到系统的配置满足如下条件则自动将运行的类认定为server-class,并且会自动设置jvm的选项(当没有手工设置这选项的时候〕而且 HOTSPOT JVM5提供了自动调优的功能,他会根据JVM的运行情况进行调整。如果没有特别的需要是不需要太多的人工干预的。SUN形象的称这个机制为“人体工学 ”(Ergonomics〕。具体可以参考http://java.sun.com/docs/hotspot/gc5.0/ergo5.html
*.具有2个或更多个物理的处理器
*.具有2G或者更多的物理内存
提示:此选项要放在所有选项的前面。例如:java -server 其他选项 java类
相关推荐
JConsole监控JVM
使用Jconsole对java的内存使用情况(JVM)进行监控参照.pdf
JVM性能监控工具VisualVM Jconsole插件所需jar包 JTop.jar 点击'JConsole Plugins'按钮 点击'Add JAR/Folder'按钮, 添加JDK_HOME/demo/management/JTop/JTop.jar7)重新打开监控页面,可以看到JConsole
使用Jconsole对java的内存使用情况(JVM)进行监控
JConsole是一个基于JMX的GUI工具,用于连接正在运行的JVM,不过此JVM需要使用可管理的模式启动。如果要把一个应用以可管理的形式启动,可以在启动是设置com.sun.management.jmxremote。JConsole能够提供被监控虚拟机...
使用Jconsole对java的内存使用情况(JVM)进行监控.pdf
部分章节如下,内容在附件里面大家随意下载,欢迎讨论交流。 2.1、JVM相关概念 1、什么是JVM 2、JVM能运行哪些编程语言 ...2、JVM监控工具之Jconsole 3、JVM监控工具之JProfile 加群:113035529 共同交流学习
JConsole是一个基于JMX的GUI工具,用于连接正在运行的JVM,使用JConsole可以很方便的监控本地或者进程的Java应用.
Java内存泄露_JVM监控工具介绍jstack_jconsole_jinfo_jmap_jdb_jstat
JVM监控工具介绍jstack, jconsole, jinfo, jmap, jdb, jstat.doc
Jconsole是Sun jdk 1.5以上版本自带的监控工具,可以对JVM进行全面的监控
本文档来源于网络,简单的介绍了jconsole,jmap,jps 详细的介绍了jstat
jconsole工具,内置在jdk8中,主要监控 JVM 的概览、内存、线程、类、vm概要、MBean等内容。内含jconsole的连接使用说明
jconsole使用手册,用于监控java运行状态,线程数,进程数,对象,jvm内存信息,时间等性能
JVM监控工具介绍:详细介绍jstack, jconsole, jinfo, jmap, jdb, jstat 等命令的使用方法
JVM监控工具介绍jstack, jconsole, jinfo, jmap, jdb, jsta
jconsole – jconsole是基于Java Management Extensions (JMX)的实时图形化监测工具,这个工具利用了内建到JVM里面的JMX指令来提供实时的性能和资源的监控,包括了Java程序的内存使用,Heap size, 线程的状态,类的...
JVM详解及优化视频教程个人觉得讲的很不错所以分享。 主要章节内容: 1、jvm内存模型 2、垃圾回收算法、机制详解 3、JVM基本监控工具jstat、jstack、jconsole等的使用 4、JVM基本调优案例讲解
NULL 博文链接:https://kennylee26.iteye.com/blog/1402260
其中,JConsole和JVisualVM是图形化工具,可以用来监控JVM的运行状态、查看内存和CPU使用情况等;而jmap、jstack和jcmd是命令行工具,可以用来诊断内存泄漏、死锁等问题。 JConsole 作用:JConsole是一个监视和管理...