beckrabbit
- 浏览: 129419 次
- 性别:
- 来自: 杭州
-
最新评论
-
amwons：
学习了，谢谢
优化JVM参数提高eclipse运行速度 -
yaoyaoershang：
究
优化JVM参数提高eclipse运行速度 -
hehaibo：
-startupplugins/org.eclipse.equ ...
优化JVM参数提高eclipse运行速度 -
hehaibo：
<div class="quote_title ...
优化JVM参数提高eclipse运行速度 -
robin35java：
刚接触了jvm，我会了Myeclipse条jvm参数，这样就可 ...
优化JVM参数提高eclipse运行速度
受此文启发： 随想配置：更快的启动eclipse
性能优化从身边做起。
首先建立评估体系，将workspace里所有的项目close掉，关闭eclipse。优化的用例就是启动eclipse，open一个项目，eclipse会自动build这个项目，保证没有感觉到明显的卡，也就是没有full GC。
开始：
eclipse.ini里加入打印gc情况的参数：
这样eclipse在运行过程中会记录gc日志，显示详细的gc情况，并打印在gc.log中，通过分析这个日志寻找eclipse的性能瓶颈和优化方式。
我最初的参数只是在原版基础上调了堆大小
将堆初始化和最大值设为一样，消除堆大小根据当前堆使用情况而变化带来的影响。
启动eclipse，发现gc.log里打出了很多full gc的日志
在启动的6秒多时间里共出现了8次full gc，所以启动慢，觉得启动时候挺卡的。从日志里可以看出来 FullGC主要是在回收tenured区和Perm区，其中Perm一直都是快满的状态，Perm : 24574K->24554K(24576K)，Perm大小在不断调整，所以需要固定Perm区的大小，保证够用，eclipse.ini里加入
再启动：发现没有full gc了只有数量比较多的minor gc，挑启动开始到启动完成的第一条和最后一条日志
这6秒中GC日志打了69次， 而内存回收率还是蛮高的 young区18880-1985=16895 jvm 46992-30098=16894 都快接近100%了，可以看出young区是由小到大在不断调整大小，所以不断GC，因此设一个初始值吧，据说设置heap的1/4比较好，那就是128M，所以eclipse.ini加入
再重启，发现GC日志就四条了，eclipse启动自然快了
但是，启动后open我的多个项目，这些项目互相依赖，eclipse自动build，感觉有点小卡，发现日志里多了4次full GC，所以就卡了…
这个时候Tenured区和Perm都还没到很接近最大值，但是为什么还有full GC呢，开始以为是JVM悲观认为Tenured区剩余空间不足以应对下一次minor GC 所以进行了full GC调整Tenured空间，索性直接增加了堆最大值到-Xmx728m（工作电脑的内存是3.5G），但重启后full gc还是有4次，而且有几次minor GC用的时间超过了0.1秒，这是因为增加了堆大小，导致GC用时也增加了，不能接受。所以还是改回-Xmx512m。
再仔细观察日志，发现Full GC (System) 字样，这个意思是eclipse里调用了System.gc()手动触发了系统GC，好吧，哥已经给你分配足够空间了，你就省省吧，在eclipse.ini里加入：
这样就差不多了，整个过程没有出现full gc，再编码2个小时，中间只出现了一次full gc，在open build某50W行+的代码的时候，eclipse还是卡了…
最后又稍微调了一下各代的大小，得到目前的参数：
另外没有去调GC策略，主要是觉得eclipse是客户端程序，默认的client单线程的GC策略应该是比较适合的，以后有时间再试试看吧。
学习了，谢谢
楼主能分析这个么？这个我的eclipse打印的Gc信息
这本书
http://book.douban.com/subject/4848587/
一直对中文的it相关书不不感兴趣~~~~~
林昊？楼主？
性能优化从身边做起。
首先建立评估体系，将workspace里所有的项目close掉，关闭eclipse。优化的用例就是启动eclipse，open一个项目，eclipse会自动build这个项目，保证没有感觉到明显的卡，也就是没有full GC。
开始：
eclipse.ini里加入打印gc情况的参数：
| -XX:+PrintGCTimeStamps |
| -XX:+PrintGCDetails |
| -verbose:gc |
| -Xloggc:gc.log |
这样eclipse在运行过程中会记录gc日志，显示详细的gc情况，并打印在gc.log中，通过分析这个日志寻找eclipse的性能瓶颈和优化方式。
我最初的参数只是在原版基础上调了堆大小
| -Xms512m |
| -Xmx512m |
将堆初始化和最大值设为一样，消除堆大小根据当前堆使用情况而变化带来的影响。
启动eclipse，发现gc.log里打出了很多full gc的日志
引用
4.226: [Full GC 4.226: [Tenured: 18470K->19304K(30544K), 0.1159544 secs] 25154K->19304K(44368K), [Perm : 24574K->24554K(24576K)], 0.1160431 secs] [Times: user=0.13 sys=0.00, real=0.13 secs]
在启动的6秒多时间里共出现了8次full gc，所以启动慢，觉得启动时候挺卡的。从日志里可以看出来 FullGC主要是在回收tenured区和Perm区，其中Perm一直都是快满的状态，Perm : 24574K->24554K(24576K)，Perm大小在不断调整，所以需要固定Perm区的大小，保证够用，eclipse.ini里加入
| -XX:PermSize=64m |
| -XX:MaxPermSize=64m |
再启动：发现没有full gc了只有数量比较多的minor gc，挑启动开始到启动完成的第一条和最后一条日志
引用
0.209: [GC 0.209: [DefNew: 4416K->511K(4928K), 0.0034707 secs] 4416K->614K(15872K), 0.0035239 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
….
6.383: [GC 6.383: [DefNew: 18880K->1985K(21184K), 0.0055311 secs] 46992K->30098K(68040K), 0.0055694 secs]
….
6.383: [GC 6.383: [DefNew: 18880K->1985K(21184K), 0.0055311 secs] 46992K->30098K(68040K), 0.0055694 secs]
这6秒中GC日志打了69次， 而内存回收率还是蛮高的 young区18880-1985=16895 jvm 46992-30098=16894 都快接近100%了，可以看出young区是由小到大在不断调整大小，所以不断GC，因此设一个初始值吧，据说设置heap的1/4比较好，那就是128M，所以eclipse.ini加入
| -Xmn128m |
再重启，发现GC日志就四条了，eclipse启动自然快了
引用
1.292: [GC 1.292: [DefNew: 104960K->10984K(118016K), 0.0334165 secs] 104960K->10984K(511232K), 0.0334603 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
2.182: [GC 2.182: [DefNew: 115944K->1852K(118016K), 0.0221714 secs] 115944K->11466K(511232K), 0.0222142 secs] [Times: user=0.00 sys=0.02, real=0.02 secs]
3.987: [GC 3.987: [DefNew: 106779K->12531K(118016K), 0.0378228 secs] 116393K->22145K(511232K), 0.0378692 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
5.377: [GC 5.377: [DefNew: 117491K->9403K(118016K), 0.0513728 secs] 127105K->31364K(511232K), 0.0514133 secs]
2.182: [GC 2.182: [DefNew: 115944K->1852K(118016K), 0.0221714 secs] 115944K->11466K(511232K), 0.0222142 secs] [Times: user=0.00 sys=0.02, real=0.02 secs]
3.987: [GC 3.987: [DefNew: 106779K->12531K(118016K), 0.0378228 secs] 116393K->22145K(511232K), 0.0378692 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
5.377: [GC 5.377: [DefNew: 117491K->9403K(118016K), 0.0513728 secs] 127105K->31364K(511232K), 0.0514133 secs]
但是，启动后open我的多个项目，这些项目互相依赖，eclipse自动build，感觉有点小卡，发现日志里多了4次full GC，所以就卡了…
引用
67.320: [Full GC (System) 67.320: [Tenured: 88847K->68809K(393216K), 0.2121213 secs] 117385K->68809K(511232K), [Perm : 41915K->41915K(65536K)], 0.2121747 secs] [Times: user=0.20 sys=0.00, real=0.20 secs]
103.759: [Full GC (System) 103.759: [Tenured: 81882K->66784K(393216K), 0.3287387 secs] 185350K->66784K(511232K), [Perm : 53464K->53414K(65536K)], 0.3287897 secs] [Times: user=0.33 sys=0.00, real=0.33 secs]
103.759: [Full GC (System) 103.759: [Tenured: 81882K->66784K(393216K), 0.3287387 secs] 185350K->66784K(511232K), [Perm : 53464K->53414K(65536K)], 0.3287897 secs] [Times: user=0.33 sys=0.00, real=0.33 secs]
这个时候Tenured区和Perm都还没到很接近最大值，但是为什么还有full GC呢，开始以为是JVM悲观认为Tenured区剩余空间不足以应对下一次minor GC 所以进行了full GC调整Tenured空间，索性直接增加了堆最大值到-Xmx728m（工作电脑的内存是3.5G），但重启后full gc还是有4次，而且有几次minor GC用的时间超过了0.1秒，这是因为增加了堆大小，导致GC用时也增加了，不能接受。所以还是改回-Xmx512m。
再仔细观察日志，发现Full GC (System) 字样，这个意思是eclipse里调用了System.gc()手动触发了系统GC，好吧，哥已经给你分配足够空间了，你就省省吧，在eclipse.ini里加入：
| -XX:+DisableExplicitGC |
这样就差不多了，整个过程没有出现full gc，再编码2个小时，中间只出现了一次full gc，在open build某50W行+的代码的时候，eclipse还是卡了…
最后又稍微调了一下各代的大小，得到目前的参数：
| -Xms512m |
| -Xmx512m |
| -XX:PermSize=96m |
| -XX:MaxPermSize=96m |
| -Xmn168m |
| -XX:+DisableExplicitGC |
另外没有去调GC策略，主要是觉得eclipse是客户端程序，默认的client单线程的GC策略应该是比较适合的，以后有时间再试试看吧。
分享到：
评论
60 楼
amwons
2013-07-12
学习了，谢谢
59 楼
yaoyaoershang
2012-08-16
究
58 楼
hehaibo
2011-04-30
-startup
plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.0.200.v20090519
-product
org.eclipse.epp.package.jee.product
--launcher.XXMaxPermSize
256M
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms512m
-Xmx512m
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-verbose:gc
-Xloggc:gc.log
我的配置
这个没有打印任何gc信息
-Xms218m
打印了2行Full G
共4行
plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.0.200.v20090519
-product
org.eclipse.epp.package.jee.product
--launcher.XXMaxPermSize
256M
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms512m
-Xmx512m
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-verbose:gc
-Xloggc:gc.log
我的配置
这个没有打印任何gc信息
-Xms218m
打印了2行Full G
共4行
57 楼
hehaibo
2011-04-30
beckrabbit 写道
受此文启发： 随想配置：更快的启动eclipse
性能优化从身边做起。
首先建立评估体系，将workspace里所有的项目close掉，关闭eclipse。优化的用例就是启动eclipse，open一个项目，eclipse会自动build这个项目，保证没有感觉到明显的卡，也就是没有full GC。
开始：
eclipse.ini里加入打印gc情况的参数：
这样eclipse在运行过程中会记录gc日志，显示详细的gc情况，并打印在gc.log中，通过分析这个日志寻找eclipse的性能瓶颈和优化方式。
我最初的参数只是在原版基础上调了堆大小
将堆初始化和最大值设为一样，消除堆大小根据当前堆使用情况而变化带来的影响。
启动eclipse，发现gc.log里打出了很多full gc的日志
在启动的6秒多时间里共出现了8次full gc，所以启动慢，觉得启动时候挺卡的。从日志里可以看出来 FullGC主要是在回收tenured区和Perm区，其中Perm一直都是快满的状态，Perm : 24574K->24554K(24576K)，Perm大小在不断调整，所以需要固定Perm区的大小，保证够用，eclipse.ini里加入
再启动：发现没有full gc了只有数量比较多的minor gc，挑启动开始到启动完成的第一条和最后一条日志
这6秒中GC日志打了69次， 而内存回收率还是蛮高的 young区18880-1985=16895 jvm 46992-30098=16894 都快接近100%了，可以看出young区是由小到大在不断调整大小，所以不断GC，因此设一个初始值吧，据说设置heap的1/4比较好，那就是128M，所以eclipse.ini加入
再重启，发现GC日志就四条了，eclipse启动自然快了
但是，启动后open我的多个项目，这些项目互相依赖，eclipse自动build，感觉有点小卡，发现日志里多了4次full GC，所以就卡了…
这个时候Tenured区和Perm都还没到很接近最大值，但是为什么还有full GC呢，开始以为是JVM悲观认为Tenured区剩余空间不足以应对下一次minor GC 所以进行了full GC调整Tenured空间，索性直接增加了堆最大值到-Xmx728m（工作电脑的内存是3.5G），但重启后full gc还是有4次，而且有几次minor GC用的时间超过了0.1秒，这是因为增加了堆大小，导致GC用时也增加了，不能接受。所以还是改回-Xmx512m。
再仔细观察日志，发现Full GC (System) 字样，这个意思是eclipse里调用了System.gc()手动触发了系统GC，好吧，哥已经给你分配足够空间了，你就省省吧，在eclipse.ini里加入：
这样就差不多了，整个过程没有出现full gc，再编码2个小时，中间只出现了一次full gc，在open build某50W行+的代码的时候，eclipse还是卡了…
最后又稍微调了一下各代的大小，得到目前的参数：
另外没有去调GC策略，主要是觉得eclipse是客户端程序，默认的client单线程的GC策略应该是比较适合的，以后有时间再试试看吧。
性能优化从身边做起。
首先建立评估体系，将workspace里所有的项目close掉，关闭eclipse。优化的用例就是启动eclipse，open一个项目，eclipse会自动build这个项目，保证没有感觉到明显的卡，也就是没有full GC。
开始：
eclipse.ini里加入打印gc情况的参数：
| -XX:+PrintGCTimeStamps |
| -XX:+PrintGCDetails |
| -verbose:gc |
| -Xloggc:gc.log |
这样eclipse在运行过程中会记录gc日志，显示详细的gc情况，并打印在gc.log中，通过分析这个日志寻找eclipse的性能瓶颈和优化方式。
我最初的参数只是在原版基础上调了堆大小
| -Xms512m |
| -Xmx512m |
将堆初始化和最大值设为一样，消除堆大小根据当前堆使用情况而变化带来的影响。
启动eclipse，发现gc.log里打出了很多full gc的日志
引用
4.226: [Full GC 4.226: [Tenured: 18470K->19304K(30544K), 0.1159544 secs] 25154K->19304K(44368K), [Perm : 24574K->24554K(24576K)], 0.1160431 secs] [Times: user=0.13 sys=0.00, real=0.13 secs]
在启动的6秒多时间里共出现了8次full gc，所以启动慢，觉得启动时候挺卡的。从日志里可以看出来 FullGC主要是在回收tenured区和Perm区，其中Perm一直都是快满的状态，Perm : 24574K->24554K(24576K)，Perm大小在不断调整，所以需要固定Perm区的大小，保证够用，eclipse.ini里加入
| -XX:PermSize=64m |
| -XX:MaxPermSize=64m |
再启动：发现没有full gc了只有数量比较多的minor gc，挑启动开始到启动完成的第一条和最后一条日志
引用
0.209: [GC 0.209: [DefNew: 4416K->511K(4928K), 0.0034707 secs] 4416K->614K(15872K), 0.0035239 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
….
6.383: [GC 6.383: [DefNew: 18880K->1985K(21184K), 0.0055311 secs] 46992K->30098K(68040K), 0.0055694 secs]
….
6.383: [GC 6.383: [DefNew: 18880K->1985K(21184K), 0.0055311 secs] 46992K->30098K(68040K), 0.0055694 secs]
这6秒中GC日志打了69次， 而内存回收率还是蛮高的 young区18880-1985=16895 jvm 46992-30098=16894 都快接近100%了，可以看出young区是由小到大在不断调整大小，所以不断GC，因此设一个初始值吧，据说设置heap的1/4比较好，那就是128M，所以eclipse.ini加入
| -Xmn128m |
再重启，发现GC日志就四条了，eclipse启动自然快了
引用
1.292: [GC 1.292: [DefNew: 104960K->10984K(118016K), 0.0334165 secs] 104960K->10984K(511232K), 0.0334603 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
2.182: [GC 2.182: [DefNew: 115944K->1852K(118016K), 0.0221714 secs] 115944K->11466K(511232K), 0.0222142 secs] [Times: user=0.00 sys=0.02, real=0.02 secs]
3.987: [GC 3.987: [DefNew: 106779K->12531K(118016K), 0.0378228 secs] 116393K->22145K(511232K), 0.0378692 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
5.377: [GC 5.377: [DefNew: 117491K->9403K(118016K), 0.0513728 secs] 127105K->31364K(511232K), 0.0514133 secs]
2.182: [GC 2.182: [DefNew: 115944K->1852K(118016K), 0.0221714 secs] 115944K->11466K(511232K), 0.0222142 secs] [Times: user=0.00 sys=0.02, real=0.02 secs]
3.987: [GC 3.987: [DefNew: 106779K->12531K(118016K), 0.0378228 secs] 116393K->22145K(511232K), 0.0378692 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
5.377: [GC 5.377: [DefNew: 117491K->9403K(118016K), 0.0513728 secs] 127105K->31364K(511232K), 0.0514133 secs]
但是，启动后open我的多个项目，这些项目互相依赖，eclipse自动build，感觉有点小卡，发现日志里多了4次full GC，所以就卡了…
引用
67.320: [Full GC (System) 67.320: [Tenured: 88847K->68809K(393216K), 0.2121213 secs] 117385K->68809K(511232K), [Perm : 41915K->41915K(65536K)], 0.2121747 secs] [Times: user=0.20 sys=0.00, real=0.20 secs]
103.759: [Full GC (System) 103.759: [Tenured: 81882K->66784K(393216K), 0.3287387 secs] 185350K->66784K(511232K), [Perm : 53464K->53414K(65536K)], 0.3287897 secs] [Times: user=0.33 sys=0.00, real=0.33 secs]
103.759: [Full GC (System) 103.759: [Tenured: 81882K->66784K(393216K), 0.3287387 secs] 185350K->66784K(511232K), [Perm : 53464K->53414K(65536K)], 0.3287897 secs] [Times: user=0.33 sys=0.00, real=0.33 secs]
这个时候Tenured区和Perm都还没到很接近最大值，但是为什么还有full GC呢，开始以为是JVM悲观认为Tenured区剩余空间不足以应对下一次minor GC 所以进行了full GC调整Tenured空间，索性直接增加了堆最大值到-Xmx728m（工作电脑的内存是3.5G），但重启后full gc还是有4次，而且有几次minor GC用的时间超过了0.1秒，这是因为增加了堆大小，导致GC用时也增加了，不能接受。所以还是改回-Xmx512m。
再仔细观察日志，发现Full GC (System) 字样，这个意思是eclipse里调用了System.gc()手动触发了系统GC，好吧，哥已经给你分配足够空间了，你就省省吧，在eclipse.ini里加入：
| -XX:+DisableExplicitGC |
这样就差不多了，整个过程没有出现full gc，再编码2个小时，中间只出现了一次full gc，在open build某50W行+的代码的时候，eclipse还是卡了…
最后又稍微调了一下各代的大小，得到目前的参数：
| -Xms512m |
| -Xmx512m |
| -XX:PermSize=96m |
| -XX:MaxPermSize=96m |
| -Xmn168m |
| -XX:+DisableExplicitGC |
另外没有去调GC策略，主要是觉得eclipse是客户端程序，默认的client单线程的GC策略应该是比较适合的，以后有时间再试试看吧。
楼主能分析这个么？这个我的eclipse打印的Gc信息
0.372: [GC 0.372: [DefNew: 10944K->1061K(12288K), 0.0076392 secs] 10944K->1061K(39616K), 0.0077243 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 0.568: [GC 0.568: [DefNew: 12005K->110K(12288K), 0.0064232 secs] 12005K->1107K(39616K), 0.0064997 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 0.778: [GC 0.778: [DefNew: 11054K->1343K(12288K), 0.0070485 secs] 12051K->2737K(39616K), 0.0071191 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 1.148: [GC 1.149: [DefNew: 12287K->1193K(12288K), 0.0108009 secs] 13681K->3920K(39616K), 0.0108830 secs] [Times: user=0.00 sys=0.02, real=0.01 secs] 2.988: [GC 2.988: [DefNew: 12103K->993K(12288K), 0.0130957 secs] 14829K->4903K(39616K), 0.0131727 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 3.346: [GC 3.346: [DefNew: 11937K->1344K(12288K), 0.0257320 secs] 15847K->8436K(39616K), 0.0258077 secs] [Times: user=0.03 sys=0.00, real=0.03 secs] 3.508: [Full GC 3.508: [Tenured: 7092K->10654K(27328K), 0.0720478 secs] 13905K->10654K(39616K), [Perm : 16383K->16383K(16384K)], 0.0721526 secs] [Times: user=0.06 sys=0.00, real=0.07 secs] 3.840: [GC 3.840: [DefNew: 11008K->1344K(12352K), 0.0176411 secs] 21662K->13860K(39680K), 0.0177151 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 4.032: [GC 4.032: [DefNew: 12352K->911K(12352K), 0.0097466 secs] 24868K->14757K(39680K), 0.0098193 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 4.363: [Full GC 4.363: [Tenured: 13845K->14934K(27328K), 0.1018547 secs] 19557K->14934K(39680K), [Perm : 20480K->20480K(20480K)], 0.1019398 secs] [Times: user=0.11 sys=0.00, real=0.10 secs] 4.792: [GC 4.792: [DefNew: 11008K->1344K(12352K), 0.0085904 secs] 25942K->16458K(39680K), 0.0086717 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 4.963: [Full GC 4.963: [Tenured: 15114K->16840K(27328K), 0.1195732 secs] 20701K->16840K(39680K), [Perm : 24575K->24575K(24576K)], 0.1197558 secs] [Times: user=0.11 sys=0.00, real=0.12 secs] 5.357: [GC 5.357: [DefNew: 11250K->1254K(12672K), 0.0078090 secs] 28091K->18095K(40740K), 0.0078924 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 5.374: [GC 5.374: [DefNew: 12515K->44K(12672K), 0.0057931 secs] 29355K->18119K(40740K), 0.0058740 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 5.386: [GC 5.386: [DefNew: 11279K->59K(12672K), 0.0009145 secs] 29355K->18135K(40740K), 0.0009581 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 5.394: [GC 5.394: [DefNew: 11274K->71K(12672K), 0.0007840 secs] 29350K->18147K(40740K), 0.0008259 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 5.400: [GC 5.400: [DefNew: 11309K->81K(12672K), 0.0007990 secs] 29385K->18157K(40740K), 0.0008430 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 5.407: [GC 5.407: [DefNew: 11337K->90K(12672K), 0.0008798 secs] 29413K->18166K(40740K), 0.0009256 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 5.712: [GC 5.712: [DefNew: 11339K->1176K(12672K), 0.0084074 secs] 29415K->19252K(40740K), 0.0084929 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 5.826: [Full GC 5.826: [Tenured: 18075K->19067K(28068K), 0.1628449 secs] 19933K->19067K(40740K), [Perm : 28671K->28658K(28672K)], 0.1630036 secs] [Times: user=0.17 sys=0.00, real=0.16 secs] 6.539: [GC 6.539: [DefNew: 12864K->1117K(14400K), 0.0089087 secs] 31931K->20185K(46180K), 0.0089865 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 6.959: [Full GC 6.959: [Tenured: 19067K->20479K(31780K), 0.1595651 secs] 24232K->20479K(46180K), [Perm : 32767K->32767K(32768K)], 0.1597195 secs] [Times: user=0.14 sys=0.02, real=0.16 secs] 7.371: [GC 7.371: [DefNew: 13760K->1664K(15424K), 0.0145568 secs] 34239K->23197K(49560K), 0.0146385 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 7.428: [Full GC 7.428: [Tenured: 21533K->24787K(34136K), 0.1806502 secs] 26096K->24787K(49560K), [Perm : 36863K->36863K(36864K)], 0.1808658 secs]
56 楼
robin35java
2011-04-15
刚接触了jvm，我会了Myeclipse条jvm参数，这样就可以在Myeclipse上做实验了，楼主强大，支持你
55 楼
Antonyxuan
2011-03-23
仔细看过楼主的优化介绍，自己弄了一下，确实挺管用。
54 楼
txr
2011-03-23
楼主，学习了，善于发现问题解决问题，这样提高自己最快的方法
53 楼
青衣秀士
2011-03-06
挺好的，跟着做了一遍，结合日志输出对GC也有了更深一层的认识，顶楼主！
52 楼
➸愛✘A'shIn信☠™
2011-03-05
楼主怎么研究出来的？
51 楼
mulangren1988
2011-03-05
beckrabbit 写道
受此文启发： 随想配置：更快的启动eclipse
性能优化从身边做起。
首先建立评估体系，将workspace里所有的项目close掉，关闭eclipse。优化的用例就是启动eclipse，open一个项目，eclipse会自动build这个项目，保证没有感觉到明显的卡，也就是没有full GC。
开始：
eclipse.ini里加入打印gc情况的参数：
这样eclipse在运行过程中会记录gc日志，显示详细的gc情况，并打印在gc.log中，通过分析这个日志寻找eclipse的性能瓶颈和优化方式。
我最初的参数只是在原版基础上调了堆大小
将堆初始化和最大值设为一样，消除堆大小根据当前堆使用情况而变化带来的影响。
启动eclipse，发现gc.log里打出了很多full gc的日志
在启动的6秒多时间里共出现了8次full gc，所以启动慢，觉得启动时候挺卡的。从日志里可以看出来 FullGC主要是在回收tenured区和Perm区，其中Perm一直都是快满的状态，Perm : 24574K->24554K(24576K)，Perm大小在不断调整，所以需要固定Perm区的大小，保证够用，eclipse.ini里加入
再启动：发现没有full gc了只有数量比较多的minor gc，挑启动开始到启动完成的第一条和最后一条日志
这6秒中GC日志打了69次， 而内存回收率还是蛮高的 young区18880-1985=16895 jvm 46992-30098=16894 都快接近100%了，可以看出young区是由小到大在不断调整大小，所以不断GC，因此设一个初始值吧，据说设置heap的1/4比较好，那就是128M，所以eclipse.ini加入
再重启，发现GC日志就四条了，eclipse启动自然快了
但是，启动后open我的多个项目，这些项目互相依赖，eclipse自动build，感觉有点小卡，发现日志里多了4次full GC，所以就卡了…
这个时候Tenured区和Perm都还没到很接近最大值，但是为什么还有full GC呢，开始以为是JVM悲观认为Tenured区剩余空间不足以应对下一次minor GC 所以进行了full GC调整Tenured空间，索性直接增加了堆最大值到-Xmx728m（工作电脑的内存是3.5G），但重启后full gc还是有4次，而且有几次minor GC用的时间超过了0.1秒，这是因为增加了堆大小，导致GC用时也增加了，不能接受。所以还是改回-Xmx512m。
再仔细观察日志，发现Full GC (System) 字样，这个意思是eclipse里调用了System.gc()手动触发了系统GC，好吧，哥已经给你分配足够空间了，你就省省吧，在eclipse.ini里加入：
这样就差不多了，整个过程没有出现full gc，再编码2个小时，中间只出现了一次full gc，在open build某50W行+的代码的时候，eclipse还是卡了…
最后又稍微调了一下各代的大小，得到目前的参数：
另外没有去调GC策略，主要是觉得eclipse是客户端程序，默认的client单线程的GC策略应该是比较适合的，以后有时间再试试看吧。
性能优化从身边做起。
首先建立评估体系，将workspace里所有的项目close掉，关闭eclipse。优化的用例就是启动eclipse，open一个项目，eclipse会自动build这个项目，保证没有感觉到明显的卡，也就是没有full GC。
开始：
eclipse.ini里加入打印gc情况的参数：
| -XX:+PrintGCTimeStamps |
| -XX:+PrintGCDetails |
| -verbose:gc |
| -Xloggc:gc.log |
这样eclipse在运行过程中会记录gc日志，显示详细的gc情况，并打印在gc.log中，通过分析这个日志寻找eclipse的性能瓶颈和优化方式。
我最初的参数只是在原版基础上调了堆大小
| -Xms512m |
| -Xmx512m |
将堆初始化和最大值设为一样，消除堆大小根据当前堆使用情况而变化带来的影响。
启动eclipse，发现gc.log里打出了很多full gc的日志
引用
4.226: [Full GC 4.226: [Tenured: 18470K->19304K(30544K), 0.1159544 secs] 25154K->19304K(44368K), [Perm : 24574K->24554K(24576K)], 0.1160431 secs] [Times: user=0.13 sys=0.00, real=0.13 secs]
在启动的6秒多时间里共出现了8次full gc，所以启动慢，觉得启动时候挺卡的。从日志里可以看出来 FullGC主要是在回收tenured区和Perm区，其中Perm一直都是快满的状态，Perm : 24574K->24554K(24576K)，Perm大小在不断调整，所以需要固定Perm区的大小，保证够用，eclipse.ini里加入
| -XX:PermSize=64m |
| -XX:MaxPermSize=64m |
再启动：发现没有full gc了只有数量比较多的minor gc，挑启动开始到启动完成的第一条和最后一条日志
引用
0.209: [GC 0.209: [DefNew: 4416K->511K(4928K), 0.0034707 secs] 4416K->614K(15872K), 0.0035239 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
….
6.383: [GC 6.383: [DefNew: 18880K->1985K(21184K), 0.0055311 secs] 46992K->30098K(68040K), 0.0055694 secs]
….
6.383: [GC 6.383: [DefNew: 18880K->1985K(21184K), 0.0055311 secs] 46992K->30098K(68040K), 0.0055694 secs]
这6秒中GC日志打了69次， 而内存回收率还是蛮高的 young区18880-1985=16895 jvm 46992-30098=16894 都快接近100%了，可以看出young区是由小到大在不断调整大小，所以不断GC，因此设一个初始值吧，据说设置heap的1/4比较好，那就是128M，所以eclipse.ini加入
| -Xmn128m |
再重启，发现GC日志就四条了，eclipse启动自然快了
引用
1.292: [GC 1.292: [DefNew: 104960K->10984K(118016K), 0.0334165 secs] 104960K->10984K(511232K), 0.0334603 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
2.182: [GC 2.182: [DefNew: 115944K->1852K(118016K), 0.0221714 secs] 115944K->11466K(511232K), 0.0222142 secs] [Times: user=0.00 sys=0.02, real=0.02 secs]
3.987: [GC 3.987: [DefNew: 106779K->12531K(118016K), 0.0378228 secs] 116393K->22145K(511232K), 0.0378692 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
5.377: [GC 5.377: [DefNew: 117491K->9403K(118016K), 0.0513728 secs] 127105K->31364K(511232K), 0.0514133 secs]
2.182: [GC 2.182: [DefNew: 115944K->1852K(118016K), 0.0221714 secs] 115944K->11466K(511232K), 0.0222142 secs] [Times: user=0.00 sys=0.02, real=0.02 secs]
3.987: [GC 3.987: [DefNew: 106779K->12531K(118016K), 0.0378228 secs] 116393K->22145K(511232K), 0.0378692 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
5.377: [GC 5.377: [DefNew: 117491K->9403K(118016K), 0.0513728 secs] 127105K->31364K(511232K), 0.0514133 secs]
但是，启动后open我的多个项目，这些项目互相依赖，eclipse自动build，感觉有点小卡，发现日志里多了4次full GC，所以就卡了…
引用
67.320: [Full GC (System) 67.320: [Tenured: 88847K->68809K(393216K), 0.2121213 secs] 117385K->68809K(511232K), [Perm : 41915K->41915K(65536K)], 0.2121747 secs] [Times: user=0.20 sys=0.00, real=0.20 secs]
103.759: [Full GC (System) 103.759: [Tenured: 81882K->66784K(393216K), 0.3287387 secs] 185350K->66784K(511232K), [Perm : 53464K->53414K(65536K)], 0.3287897 secs] [Times: user=0.33 sys=0.00, real=0.33 secs]
103.759: [Full GC (System) 103.759: [Tenured: 81882K->66784K(393216K), 0.3287387 secs] 185350K->66784K(511232K), [Perm : 53464K->53414K(65536K)], 0.3287897 secs] [Times: user=0.33 sys=0.00, real=0.33 secs]
这个时候Tenured区和Perm都还没到很接近最大值，但是为什么还有full GC呢，开始以为是JVM悲观认为Tenured区剩余空间不足以应对下一次minor GC 所以进行了full GC调整Tenured空间，索性直接增加了堆最大值到-Xmx728m（工作电脑的内存是3.5G），但重启后full gc还是有4次，而且有几次minor GC用的时间超过了0.1秒，这是因为增加了堆大小，导致GC用时也增加了，不能接受。所以还是改回-Xmx512m。
再仔细观察日志，发现Full GC (System) 字样，这个意思是eclipse里调用了System.gc()手动触发了系统GC，好吧，哥已经给你分配足够空间了，你就省省吧，在eclipse.ini里加入：
| -XX:+DisableExplicitGC |
这样就差不多了，整个过程没有出现full gc，再编码2个小时，中间只出现了一次full gc，在open build某50W行+的代码的时候，eclipse还是卡了…
最后又稍微调了一下各代的大小，得到目前的参数：
| -Xms512m |
| -Xmx512m |
| -XX:PermSize=96m |
| -XX:MaxPermSize=96m |
| -Xmn168m |
| -XX:+DisableExplicitGC |
另外没有去调GC策略，主要是觉得eclipse是客户端程序，默认的client单线程的GC策略应该是比较适合的，以后有时间再试试看吧。
50 楼
pengsuyun
2010-11-08
只能跟着楼主操作，意思不是很明白，eclipse的速度感觉快了点，还是有点悲剧！
49 楼
ykxian01
2010-11-01
实战性很强的贴子。确实有用。
48 楼
opleo
2010-10-12
-XX:CMSFullGCsBeforeCompaction=5 to 1, -XX:CMSInitiatingOccupancyFraction=60 to 50, -XX:SurvivorRatio=8 to 6, Add: -XX:+UseCMSInitiatingOccupancyOnly=true
47 楼
volking
2010-09-16
mark.
46 楼
snake1987
2010-09-09
beckrabbit 写道
snake1987 写道
授人以鱼不如授人以渔
楼主，能介绍下学习调优，需要一些什么基础知识吗？能介绍一些相关的经典书籍吗？
谢谢了
楼主，能介绍下学习调优，需要一些什么基础知识吗？能介绍一些相关的经典书籍吗？
谢谢了
这本书
http://book.douban.com/subject/4848587/
一直对中文的it相关书不不感兴趣~~~~~
林昊？楼主？
45 楼
lkjxshi
2010-09-09
学习一下。。加上了好像速度差不多-.-
44 楼
wenlian13
2010-09-08
恩，不错的文章
43 楼
smallhand
2010-09-08
确实不错，但是参数之间也是有限制的
42 楼
BruceXX
2010-09-08
明显你是用内存消耗来加载启动速度，可调可不调也罢。。。卡的时候是因为JVM在分配内存，这个和你自己启动的时候分配超大的内存空间没什么实质作用。
41 楼
xiaoxiaoniao
2010-09-08
文章让我的工作变得很有趣了。
喜欢那种一切尽在掌握的感觉。
只是Windows什么时候可以换成linux就开心了。
喜欢那种一切尽在掌握的感觉。
只是Windows什么时候可以换成linux就开心了。
发表评论
-
今年尾牙我们部门拍的搞笑短片，讲述项目开发的事～
2010-02-09 13:11 1508三个女人和二十个男人的故事 -
palm的热门程序大奖赛开始了，冠军10万美刀
2010-02-02 09:31 1225大赛名称叫Hot Apps 详见这里http://develo ... -
我在market发布的第一个android game和一些心得
2010-01-09 17:00 1570这是我的第一个android游戏，玩法很简单， ... -
囧 wubi方式无法安装ubuntu9.04的原因
2009-04-23 19:24 3199下载了ubuntu9.04后双击wubi.exe一闪而过，查看 ... -
google收购skype的话 中国移动们就傻眼了
2008-04-06 12:11 2705假设google把skype收购过来，那么在android手机 ... -
虽然我不相信神，但今天确实看到“神”了
2008-03-29 20:57 1651最新一期的死神漫画也就是-108话（番外篇，讲100多年前的事 ... -
这safari也太快了吧...
2007-12-29 16:24 1283测试了一下，IE6 FF2 SAFARI3.0.4B ... -
推荐几个不错的igoogle小工具
2007-12-23 21:59 4062首先这几个都要用台湾google才能添加，要先www.goog ... -
safari3.0.4试用
2007-12-23 01:52 1688看了javaeye上关于js在主流浏览器里速度测试的新 ...
相关推荐
其中，设置合适的JVM（Java虚拟机）参数是优化Eclipse运行性能的重要手段之一。本文将详细介绍如何设置Eclipse的JVM参数，并解释这些参数的意义及其对Eclipse性能的影响。 #### 二、Eclipse与JVM的关系 Eclipse...
Java的安装；...优化JVM参数提高eclipse运行速度；Tomcat JVM优化一例；linux下Nginx+tomcat整合的安装与配置；Memcached安装；memcache集群配置；JMS安装；JMS集群配置；Nginx反向代理；防火墙配置
本文将深入探讨如何通过调整JVM参数来优化Eclipse的启动和运行速度，旨在为开发者提供实用的性能调优策略。 #### 二、JVM参数详解 ##### 1. **-Xverify:none** 关闭Java字节码验证，这一步骤可以显著加速类的加载...
本文将详细探讨如何通过调整JVM参数来优化Eclipse的性能，特别是针对启动时间和运行速度。 #### 二、JVM参数概述 Java虚拟机（JVM）提供了一系列的参数选项来帮助开发者调整内存分配和垃圾回收等行为，这对于提高...
本文将详细介绍Eclipse运行时可以使用的命令行参数，帮助用户更好地理解和掌握如何优化和定制自己的开发环境。 #### 基本概念 在启动Eclipse时，可以通过命令行传递一系列参数来定制其行为和性能。这些参数主要...
1. **启动速度优化**：可以通过减少工作空间中的项目数量，禁用不必要的插件，以及使用eclipse -clean启动来提高Eclipse的启动速度。另外，保持Eclipse的更新也是提高性能的关键，定期检查并安装最新的版本和补丁。 ...
通过在Eclipse配置文件（eclipse.ini）中指定JVM参数“-vm”，我们可以指定Eclipse运行所使用的JRE路径，从而避免在启动时搜索JRE，加快启动速度。 其次，Eclipse在启动时默认会激活一系列的插件，这些插件可能并...
为了提高Eclipse的启动速度和运行效率，我们可以对Eclipse的配置进行优化。以下是一些关键的优化策略，主要集中在JVM（Java虚拟机）参数的调整和Eclipse配置文件的修改上。 1. **JVM 参数优化**： - `-server`：...
在深入探讨《eclipse.ini内存设置各参数含义》这一主题之前，我们首先应当明确eclipse.ini文件在Eclipse集成开发环境中的重要性及其如何通过调整内存配置参数来优化Eclipse的运行性能。以下是对该主题的详细解析： ...
通过对 Eclipse 的 JVM 参数、启动项以及一些高级配置的优化，我们可以显著提高 Eclipse 的启动速度和运行效率。当然，具体的优化策略还需要根据个人的工作环境和需求进行调整。希望上述内容能帮助开发者们更好地...
对于8GB内存的系统，保持默认配置即可，因为8GB通常足够Eclipse运行。 其次，禁用不必要的启动项可以加快Eclipse的启动速度。许多启动项在日常开发中可能并未使用，所以取消这些启动项的勾选可以节省内存，提高启动...
9. **硬件升级**：如果以上优化措施仍无法满足需求，考虑升级硬件，如增加RAM或使用固态硬盘，可以显著提升Eclipse的运行速度。 10. **工作流优化**：良好的编程习惯也能间接提高Eclipse的性能，比如合理划分模块，...
实战：Eclipse运行速度调优。案例分析。高性能硬件上的程序部署策略
6. **系统资源监控**: 当遇到性能瓶颈时，合理调整JVM参数，定期清理和优化工作空间，可以有效提升Eclipse的响应速度和稳定性。 综上所述，熟练掌握Eclipse的快捷键和启动参数，不仅能够显著提高编码效率，还能针对...
通常，你可以通过修改eclipse.ini文件来设置这些参数，但某些插件提供了更直观的界面，使用户在Eclipse运行时就能进行调整。 "超爽，多个eclipse之间，eclipse与其它程序之间快速切换，没有一点卡的现象"这部分描述...
### MyEclipse启动和运行速度优化 在日常开发过程中，我们经常会遇到MyEclipse启动慢、运行卡顿等问题，这不仅影响工作效率，还可能导致代码编辑和调试效率降低。本文将针对这些问题提供一系列优化建议，帮助提升...
2. **在Eclipse中配置JRE**：打开Eclipse，依次点击`Preferences -> Java -> Installed JREs -> JDK 1.6.0`，在`Default VM Arguments`中输入`-Xms256m -Xmx1024m`，指定Eclipse运行时的初始堆内存为256MB，最大堆...
3. **JVM 调优**：Java虚拟机的性能优化是软件开发中的重要环节，通过调整JVM参数，可以优化内存分配、减少垃圾回收频率，提高程序响应速度和系统资源利用率。Showtime插件让这一过程更为直观和便捷。 4. **与...
在Java开发中，Eclipse作为常用的集成开发环境，其启动速度和运行效率对开发者的工作效率有着直接影响。本文将分享一个基于旧版环境（Dell E5410，Intel i3 CPU M 370，2GB内存，32位Windows XP，Java HotSpot ...