JVM内存调优

JVM 几个重要的参数

Linux下修改JVM内存大小: linux下tomcat的参数JAVA_OPTS必须设在catalina.sh中cygwin=false前

 

要添加在tomcat 的bin 下catalina.sh 里，位置cygwin=false前 。注意linux下设置JAVA_OPTS需要把引号带上,红色的为新添加的.

# OS specific support.  $var _must_ be set to either true or false.
JAVA_OPTS="$JAVA_OPTS -Xms1200m -Xmx1200m -Xss1024K -XX:PermSize=128m -XX:MaxPermSize=256m"
cygwin=false

Linux:  命令来修改参数

export JAVA_OPTS="-Xms256m -Xmx512m"

Windows:  set JAVA_OPTS="-Xms256m -Xmx512m"

 

执行启动设置Jvm参数的操作。

1)
$ java -jar -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=128m -Xms1024m -Xmx1024m -Xmn256m -Xss256k -XX:SurvivorRatio=8 -XX:+UseConcMarkSweepGC demoproject-1.0.0.jar
2)
java -server -Xms32m -Xmx32m -jar mybatis05-0.0.1-SNAPSHOT.jar

1   项目先用maven 打包，然后直接用java -service命令带参数，设置JVM启动内存大小
2   容器的话，就配置在启动脚本里runshell.sh 里可以一起启动，
3  如果在Tomcat里配置的话，catalina.sh 里配置 JAVA_OPTS  JVM优化参数

 

<本文提供的设置仅仅是在高压力，多CPU，高内存环境下设置>

最近对JVM的参数重新看了下，把应用的JVM参数调整了下。

1 几个重要的参数

-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()

-XX:MaxPermSize=128m:设置持久代大小

另外 -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 打印参数

-Xms值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存

-Xmn350M -> -Xmn800M   年轻代，一般情况下是默认的，这里设置了一个范围，整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。 

2 关于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

 

-XX:+UseCMSInitiatingOccupancyOnly 仅仅使用手动定义初始化定义开始CMS收集

-XX:CMSInitiatingOccupancyFraction=70 CMS堆上，使用70％后开始CMS收集。

使用CMS的好处是用尽量少的新生代、，我的经验值是128M－256M，然后老生代利用CMS并行收集，这样能保证系统低延迟的吞吐效率。实际上cms的收集停顿时间非常的短，2G的内存，大约20－80ms的应用程序停顿时间。

 

 

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 锁机制的性能改善。

elipse运行环境配置JVM参数调优

 

 

参考 资料   https://www.cnblogs.com/likehua/p/3369823.html