jvm参数调优,及参数配置
2015-12-01 09:29
513 查看
linux 配置tomcat jvm8参数:
JAVA_OPTS='-server -Xmx2048m -Xms2048m -XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256m -XX:+UseConcMarkSweepGC -verbose:gc -XX:+PrintGCDetails -Xloggc:/usr/local/tomcat7/logs/gc.log'
-XX:ParallelGCThreads=6 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:MaxTenuringThreshold=5 -XX:SurvivorRatio=8 -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -Xloggc:/var/log/boss/gc-a.log -Djava.awt.headless=true -XX:+DisableExplicitGC -Dlog.home=/var/log/boss/boss-a
-Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false'
#JAVA_OPTS='-server -Xms2560m -Xmx2560m -Xmn768m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:ParallelGCThreads=6 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:MaxTenuringThreshold=5 -XX:SurvivorRatio=8 -verbose:gc -XX:+PrintGCDetails -Xloggc:/var/log/boss/gc-a.log
-Djava.awt.headless=true -XX:+ExplicitGCInvokesConcurrent -Dlog.home=/var/log/boss/boss-a -Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false'
#JAVA_OPTS='-server -Xms2048m -Xmx2048m -Xmn768m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:ParallelGCThreads=4 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Djava.awt.headless=true -XX:+DisableExplicitGC -Xloggc:/var/log/boss/gc-a.log -Dlog.home=/var/log/boss/boss-a'
#JAVA_OPTS='-server -Xms2048m -Xmx2048m -Xmn512m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:ParallelGCThreads=4 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Djava.awt.headless=true -XX:+DisableExplicitGC -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGCDetails -XX:+PrintHeapAtGC
-Xloggc:/var/log/boss/gc-a.log -Dlog.home=/var/log/boss/boss-a -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -XX:+ExplicitGCInvokesConcurrent'
其它重要选项
-verbose:gc
-XX:+UseParallelOldGC(请注意,并行缩并在与并发标记清除(mark-sweep)收集器结合使用时不可用;它只能和并行年轻代收集器(-XX:+UseParallelGC)一起使用)
提示:一般的Young Generation的大小是整个Heap size的1/4。Young generation的minor收集率应一般在70%以上。当然在实际的应用中需要根据具体情况进行调整。
http://blog.csdn.net/feng_sundy/archive/2007/01/02/1472316.aspx http://www.tot.name/show/3/7/20061112220201.htm http://calvin.iteye.com/blog/212967
GC日志分析工具:
GC portal
http://java.sun.com/developer/technicalArticles/Programming/GCPortal/
HPjmeter
Jtune
gcviewer
JVM 选项全集:
http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
调优总结:
http://unixboy.iteye.com/blog/174173
http://calvin.iteye.com/blog/91905
http://wxw850227.iteye.com/blog/255242
http://sdh5724.iteye.com/blog/283977
<本文提供的设置仅仅是在高压力, 多CPU, 高内存环境下设置>
最近对JVM的参数重新看了下, 把应用的JVM参数调整了下。 几个重要的参数
-server -Xmx3g -Xms3g -XX:MaxPermSize=128m
-XX:NewRatio=1 eden/old 的比例
-XX:SurvivorRatio=8 s/e的比例
-XX:+UseParallelGC
-XX:ParallelGCThreads=8
-XX:+UseParallelOldGC 这个是JAVA 6出现的参数选项
-XX:LargePageSizeInBytes=128m 内存页的大小, 不可设置过大, 会影响Perm的大小。
-XX:+UseFastAccessorMethods 原始类型的快速优化
-XX:+DisableExplicitGC 关闭System.gc()
另外 -Xss 是线程栈的大小, 这个参数需要严格的测试, 一般小的应用, 如果栈不是很深, 应该是128k够用的, 不过,我们的应用调用深度比较大, 还需要做详细的测试。 这个选项对性能的影响比较大。 建议使用256K的大小.
例子:
-server -Xmx3g -Xms3g -Xmn=1g -XX:MaxPermSize=128m -Xss256k -XX:MaxTenuringThreshold=10 -XX:+DisableExplicitGC -XX:+UseParallelGC -XX:+UseParallelOld GC -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+AggressiveOpts -XX:+UseBiasedLocking
-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCTimeStamps -XX:+PrintGCDetails 打印参数
=================================================================
另外对于大内存设置的要求:
Linux :
Large page support is included in 2.6 kernel. Some vendors have backported the code to their 2.4 based releases. To check if your system can support large page memory, try the following:
If the output shows the three "Huge" variables then your system can support large page memory, but it needs to be configured. If the command doesn't print out anything, then large page support is not available. To configure the system to use large page
memory, one must log in as root, then:
Increase SHMMAX value. It must be larger than the Java heap size. On a system with 4 GB of physical RAM (or less) the following will make all the memory sharable:
Specify the number of large pages. In the following example 3 GB of a 4 GB system are reserved for large pages (assuming a large page size of 2048k, then 3g = 3 x 1024m = 3072m = 3072
* 1024k = 3145728k, and 3145728k / 2048k = 1536):
Note the /proc values will reset after reboot so you may want to set them in an init script (e.g. rc.local or sysctl.conf).
=============================================
这个设置, 目前观察下来的结果是EDEN区域收集明显速度比较快, 最多几个ms, 但是,对于FGC, 大约需要0。9, 但是发生时间非常的长, 应该是影响不大。 但是对于非web应用的中间件服务, 这个设置很要不得, 可能导致很严重延迟效果. 因此, CMS必然需要被使用, 下面是CMS的重要参数介绍
关于CMS的设置:
使用CMS的前提条件是你有比较的长生命对象, 比如有200M以上的OLD堆占用。 那么这个威力非常猛, 可以极大的提高的FGC的收集能力。 如果你的OLD占用非常的少, 别用了, 绝对降低你性能, 因为CMS收集有2个STOP WORLD的行为。 OLD少的清情况, 根据我的测试, 使用并行收集参数会比较好。
-XX:+UseConcMarkSweepGC 使用CMS内存收集
-XX:+AggressiveHeap 特别说明下:(我感觉对于做java cache应用有帮助)
试图是使用大量的物理内存
长时间大内存使用的优化,能检查计算资源(内存, 处理器数量)
至少需要256MB内存
大量的CPU/内存, (在1.4.1在4CPU的机器上已经显示有提升)
-XX:+UseParNewGC 允许多线程收集新生代
-XX:+CMSParallelRemarkEnabled 降低标记停顿
-XX+UseCMSCompactAtFullCollection 在FULL GC的时候, 压缩内存, CMS是不会移动内存的, 因此, 这个非常容易产生碎片, 导致内存不够用, 因此, 内存的压缩这个时候就会被启用。 增加这个参数是个好习惯。
压力测试下合适结果:
-server -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:MaxTenuringThreshold=31 -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection
-XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods
由于Jdk1.5.09及之前的bug, 因此, CMS下的GC, 在这些版本的表现是十分糟糕的。 需要另外2个参数来控制cms的启动时间:
-XX:+UseCMSInitiatingOccupancyOnly 仅仅使用手动定义初始化定义开始CMS收集
-XX:CMSInitiatingOccupancyFraction=70 CMS堆上, 使用70%后开始CMS收集。
使用CMS的好处是用尽量少的新生代、,我的经验值是128M-256M, 然后老生代利用CMS并行收集, 这样能保证系统低延迟的吞吐效率。 实际上cms的收集停顿时间非常的短,2G的内存, 大约20-80ms的应用程序停顿时间。
=========系统情况介绍========================
这个例子是测试系统12小时运行后的情况:
$uname -a
2.4.21-51.EL3.customsmp #1 SMP Fri Jun 27 10:44:12 CST 2008 i686 i686 i386 GNU/Linux
$ free -m
total used free shared buffers cached
Mem: 3995 3910 85 0 162 1267
-/+ buffers/cache: 2479 1515
Swap: 2047 0 2047
$ jstat -gcutil 23959 1000
S0 S1 E O P YGC YGCT FGC FGCT GCT
59.06 0.00 45.77 44.45 56.88 15204 324.023 66 1.668 325.691
0.00 39.66 27.53 44.73 56.88 15205 324.046 66 1.668 325.715
53.42 0.00 22.80 44.73 56.88 15206 324.073 66 1.668 325.741
0.00 44.90 13.73 44.76 56.88 15207 324.094 66 1.668 325.762
51.70 0.00 19.03 44.76 56.88 15208 324.118 66 1.668 325.786
0.00 61.62 19.44 44.98 56.88 15209 324.148 66 1.668 325.816
53.03 0.00 14.00 45.09 56.88 15210 324.172 66 1.668 325.840
53.03 0.00 87.87 45.09 56.88 15210 324.172 66 1.668 325.840
b542
0.00 50.49 72.00 45.22 56.88 15211 324.198 66 1.668 325.866
GC参数配置:
JAVA_OPTS=" -server -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:MaxTenuringThreshold=31 -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled
-XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 "
实际上我们可以看到并行young gc执行时间是: 324.198s/15211=20ms, cms的执行时间是 1.668/66=25ms. 当然严格来说, 这么算是不对的, 世界停顿的时间要比这是数据稍微大5-10ms. 对我们来说如果不输出日志, 对我们是有参考意义的。
32位系统下, 设置成2G, 非常危险, 除非你确定你的应用占用的native内存很少, 不然可能导致jvm直接crash。
-XX:+AggressiveOpts 加快编译
-XX:+UseBiasedLocking 锁机制的性能改善。
JAVA_OPTS='-server -Xmx2048m -Xms2048m -XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256m -XX:+UseConcMarkSweepGC -verbose:gc -XX:+PrintGCDetails -Xloggc:/usr/local/tomcat7/logs/gc.log'
-Xloggc:指定gc日志打印位置
缺省的GC日志时输出到终端的,使用-Xloggc:也可以输出到指定的文件。需要注意这个参数隐式的设置了参数-XX:+PrintGC和-XX:+PrintGCTimeStamps,但为了以防在新版本的JVM中有任何变化,我仍建议显示的设置这些参数。-Xloggc:/usr/logs/gc.log
JAVA_OPTS='-server -Xms2560m -Xmx2560m -Xmn768m -XX:PermSize=128m -XX:MaxPermSize=256m <strong>-Xss256k </strong>-XX:ParallelGCThreads=6 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:MaxTenuringThreshold=5 -XX:SurvivorRatio=8 -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -Xloggc:/var/log/boss/gc-a.log -Djava.awt.headless=true -XX:+DisableExplicitGC -Dlog.home=/var/log/boss/boss-a
-Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false'
#JAVA_OPTS='-server -Xms2560m -Xmx2560m -Xmn768m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:ParallelGCThreads=6 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:MaxTenuringThreshold=5 -XX:SurvivorRatio=8 -verbose:gc -XX:+PrintGCDetails -Xloggc:/var/log/boss/gc-a.log
-Djava.awt.headless=true -XX:+ExplicitGCInvokesConcurrent -Dlog.home=/var/log/boss/boss-a -Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false'
#JAVA_OPTS='-server -Xms2048m -Xmx2048m -Xmn768m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:ParallelGCThreads=4 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Djava.awt.headless=true -XX:+DisableExplicitGC -Xloggc:/var/log/boss/gc-a.log -Dlog.home=/var/log/boss/boss-a'
#JAVA_OPTS='-server -Xms2048m -Xmx2048m -Xmn512m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:ParallelGCThreads=4 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Djava.awt.headless=true -XX:+DisableExplicitGC -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGCDetails -XX:+PrintHeapAtGC
-Xloggc:/var/log/boss/gc-a.log -Dlog.home=/var/log/boss/boss-a -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -XX:+ExplicitGCInvokesConcurrent'
其它重要选项
-verbose:gc
-XX:+UseParallelOldGC(请注意,并行缩并在与并发标记清除(mark-sweep)收集器结合使用时不可用;它只能和并行年轻代收集器(-XX:+UseParallelGC)一起使用)
提示:一般的Young Generation的大小是整个Heap size的1/4。Young generation的minor收集率应一般在70%以上。当然在实际的应用中需要根据具体情况进行调整。
http://blog.csdn.net/feng_sundy/archive/2007/01/02/1472316.aspx http://www.tot.name/show/3/7/20061112220201.htm http://calvin.iteye.com/blog/212967
-Xrunhprof:heap=sites
GC日志分析工具:
GC portal
http://java.sun.com/developer/technicalArticles/Programming/GCPortal/
HPjmeter
Jtune
gcviewer
JVM 选项全集:
http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
调优总结:
http://unixboy.iteye.com/blog/174173
http://calvin.iteye.com/blog/91905
http://wxw850227.iteye.com/blog/255242
http://sdh5724.iteye.com/blog/283977
<本文提供的设置仅仅是在高压力, 多CPU, 高内存环境下设置>
最近对JVM的参数重新看了下, 把应用的JVM参数调整了下。 几个重要的参数
-server -Xmx3g -Xms3g -XX:MaxPermSize=128m
-XX:NewRatio=1 eden/old 的比例
-XX:SurvivorRatio=8 s/e的比例
-XX:+UseParallelGC
-XX:ParallelGCThreads=8
-XX:+UseParallelOldGC 这个是JAVA 6出现的参数选项
-XX:LargePageSizeInBytes=128m 内存页的大小, 不可设置过大, 会影响Perm的大小。
-XX:+UseFastAccessorMethods 原始类型的快速优化
-XX:+DisableExplicitGC 关闭System.gc()
另外 -Xss 是线程栈的大小, 这个参数需要严格的测试, 一般小的应用, 如果栈不是很深, 应该是128k够用的, 不过,我们的应用调用深度比较大, 还需要做详细的测试。 这个选项对性能的影响比较大。 建议使用256K的大小.
例子:
-server -Xmx3g -Xms3g -Xmn=1g -XX:MaxPermSize=128m -Xss256k -XX:MaxTenuringThreshold=10 -XX:+DisableExplicitGC -XX:+UseParallelGC -XX:+UseParallelOld GC -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+AggressiveOpts -XX:+UseBiasedLocking
-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCTimeStamps -XX:+PrintGCDetails 打印参数
=================================================================
另外对于大内存设置的要求:
Linux :
Large page support is included in 2.6 kernel. Some vendors have backported the code to their 2.4 based releases. To check if your system can support large page memory, try the following:
# cat /proc/meminfo | grep Huge HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kB #
If the output shows the three "Huge" variables then your system can support large page memory, but it needs to be configured. If the command doesn't print out anything, then large page support is not available. To configure the system to use large page
memory, one must log in as root, then:
Increase SHMMAX value. It must be larger than the Java heap size. On a system with 4 GB of physical RAM (or less) the following will make all the memory sharable:
# echo 4294967295 > /proc/sys/kernel/shmmax
Specify the number of large pages. In the following example 3 GB of a 4 GB system are reserved for large pages (assuming a large page size of 2048k, then 3g = 3 x 1024m = 3072m = 3072
* 1024k = 3145728k, and 3145728k / 2048k = 1536):
# echo 1536 > /proc/sys/vm/nr_hugepages
Note the /proc values will reset after reboot so you may want to set them in an init script (e.g. rc.local or sysctl.conf).
=============================================
这个设置, 目前观察下来的结果是EDEN区域收集明显速度比较快, 最多几个ms, 但是,对于FGC, 大约需要0。9, 但是发生时间非常的长, 应该是影响不大。 但是对于非web应用的中间件服务, 这个设置很要不得, 可能导致很严重延迟效果. 因此, CMS必然需要被使用, 下面是CMS的重要参数介绍
关于CMS的设置:
使用CMS的前提条件是你有比较的长生命对象, 比如有200M以上的OLD堆占用。 那么这个威力非常猛, 可以极大的提高的FGC的收集能力。 如果你的OLD占用非常的少, 别用了, 绝对降低你性能, 因为CMS收集有2个STOP WORLD的行为。 OLD少的清情况, 根据我的测试, 使用并行收集参数会比较好。
-XX:+UseConcMarkSweepGC 使用CMS内存收集
-XX:+AggressiveHeap 特别说明下:(我感觉对于做java cache应用有帮助)
试图是使用大量的物理内存
长时间大内存使用的优化,能检查计算资源(内存, 处理器数量)
至少需要256MB内存
大量的CPU/内存, (在1.4.1在4CPU的机器上已经显示有提升)
-XX:+UseParNewGC 允许多线程收集新生代
-XX:+CMSParallelRemarkEnabled 降低标记停顿
-XX+UseCMSCompactAtFullCollection 在FULL GC的时候, 压缩内存, CMS是不会移动内存的, 因此, 这个非常容易产生碎片, 导致内存不够用, 因此, 内存的压缩这个时候就会被启用。 增加这个参数是个好习惯。
压力测试下合适结果:
-server -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:MaxTenuringThreshold=31 -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection
-XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods
由于Jdk1.5.09及之前的bug, 因此, CMS下的GC, 在这些版本的表现是十分糟糕的。 需要另外2个参数来控制cms的启动时间:
-XX:+UseCMSInitiatingOccupancyOnly 仅仅使用手动定义初始化定义开始CMS收集
-XX:CMSInitiatingOccupancyFraction=70 CMS堆上, 使用70%后开始CMS收集。
使用CMS的好处是用尽量少的新生代、,我的经验值是128M-256M, 然后老生代利用CMS并行收集, 这样能保证系统低延迟的吞吐效率。 实际上cms的收集停顿时间非常的短,2G的内存, 大约20-80ms的应用程序停顿时间。
=========系统情况介绍========================
这个例子是测试系统12小时运行后的情况:
$uname -a
2.4.21-51.EL3.customsmp #1 SMP Fri Jun 27 10:44:12 CST 2008 i686 i686 i386 GNU/Linux
$ free -m
total used free shared buffers cached
Mem: 3995 3910 85 0 162 1267
-/+ buffers/cache: 2479 1515
Swap: 2047 0 2047
$ jstat -gcutil 23959 1000
S0 S1 E O P YGC YGCT FGC FGCT GCT
59.06 0.00 45.77 44.45 56.88 15204 324.023 66 1.668 325.691
0.00 39.66 27.53 44.73 56.88 15205 324.046 66 1.668 325.715
53.42 0.00 22.80 44.73 56.88 15206 324.073 66 1.668 325.741
0.00 44.90 13.73 44.76 56.88 15207 324.094 66 1.668 325.762
51.70 0.00 19.03 44.76 56.88 15208 324.118 66 1.668 325.786
0.00 61.62 19.44 44.98 56.88 15209 324.148 66 1.668 325.816
53.03 0.00 14.00 45.09 56.88 15210 324.172 66 1.668 325.840
53.03 0.00 87.87 45.09 56.88 15210 324.172 66 1.668 325.840
b542
0.00 50.49 72.00 45.22 56.88 15211 324.198 66 1.668 325.866
GC参数配置:
JAVA_OPTS=" -server -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:MaxTenuringThreshold=31 -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled
-XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 "
实际上我们可以看到并行young gc执行时间是: 324.198s/15211=20ms, cms的执行时间是 1.668/66=25ms. 当然严格来说, 这么算是不对的, 世界停顿的时间要比这是数据稍微大5-10ms. 对我们来说如果不输出日志, 对我们是有参考意义的。
32位系统下, 设置成2G, 非常危险, 除非你确定你的应用占用的native内存很少, 不然可能导致jvm直接crash。
-XX:+AggressiveOpts 加快编译
-XX:+UseBiasedLocking 锁机制的性能改善。
相关文章推荐
- win7+vs2010的程序移植到win8+vs2013
- day6 python学习随笔。
- [APUE]再读之文件和目录
- Hbase 知识点记录总结(1)
- JSON语法(3)
- Java的接口及实例
- c++删除文件
- Java 的 MD5 加密——Java自带的 MD5 加密
- 关于js日期--第二个日期比第一个日期固定大280天
- python:random模块
- java中this的用法
- 测试测试
- maven零基础入门小节和简易理解
- center os 7开启ftp功能
- 详细了解java中的null
- IO流--文本文件读取
- mosquitto ubuntu下编译和安装
- 用git difff 生成补丁
- echarts 生成统计图时,自动保存图片到服务器,并使用freemarker生成word
- MDC介绍 -- 一种多线程下日志管理实践方式