JVM生产环境参数实例及分析[转]

java application项目（非web项目）

改进前：

-Xms128m-Xmx128m-XX:NewSize=64m-XX:PermSize=64m-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=78-XX:ThreadStackSize=128-Xloggc:logs/gc.log-Dsun.rmi.dgc.server.gcInterval=3600000-Dsun.rmi.dgc.client.gcInterval=3600000-Dsun.rmi.server.exceptionTrace=true

问题:

  1. permsize 设置较小,很容易达到报警范围(0.8)
  2. 没有设置MaxPermSize，堆增长会带来额外压力。
  3. NewSize较大，old gen 剩余空间64m，一方面可能会带来old区容易增长到报警范围（监控数据显示oldgenused长期在50m左右，接近78%，容易出现full gc）,另一方面也存在promontion fail风险

改进后：

-Xms128m-Xmx128m-Xmn24m-XX:PermSize=80m-XX:MaxPermSize=80m-Xss256k-XX:SurvivorRatio=1-XX:MaxTenuringThreshold=20-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=75-XX:+UseCMSCompactAtFullCollection-XX:+CMSParallelRemarkEnabled-XX:CMSFullGCsBeforeCompaction=2-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:logs/gc.log-Dsun.rmi.dgc.server.gcInterval=3600000-Dsun.rmi.dgc.client.gcInterval=3600000-Dsun.rmi.server.exceptionTrace=true

修改点：

  1. PermSize与MaxPermSize都设置为80，一方面避免non heap warn(报警阀值0.8 非对内存一般占用到60M以内），一方面避免堆伸缩带来的压力
  2. 通过设置Xmn=24M及SurvivorRatio=1 使得Eden区=from space=to  space=8M,降低了Eden区大小，降低YGC的时间(降低到3-4ms左右),同时通过设MaxTenuringThreshold=20，使得old gen的增长很缓慢。带来的问题是YGC的次数明显提高了很多。
  3. 其他参数优化 修改后带来的好处见JVM参数设置

再次改进后

-Xms128m-Xmx128m-Xmn36m-XX:PermSize=80m-XX:MaxPermSize=80m-Xss256k-XX:SurvivorRatio=1-XX:MaxTenuringThreshold=20-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=73-XX:+UseCMSCompactAtFullCollection-XX:+CMSParallelRemarkEnabled-XX:CMSFullGCsBeforeCompaction=2-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:logs/gc.log-Dsun.rmi.dgc.server.gcInterval=3600000-Dsun.rmi.dgc.client.gcInterval=3600000-Dsun.rmi.server.exceptionTrace=true

修改点：

在上面的基础上调整Xmn大小到36M，设置CMSInitiatingOccupancyFraction=73。

Dden区与Survivor区大小都增加到12M，通过CMSInitiatingOccupancyFraction计算公式,计算得出value为73是，可以避免promotion faild问题，同时满足堆内存监控报警值在80%：内存大小128M*80%=102.4M 102.4M-36M=66.4M(老生代达到此值报警） 老生代达到67.15M（92M*0.73）将发生Full GC，所以在老生代大小达到66.4M时也就是WARN报警时将很有可能出现Full GC。

增大了Eden和Survivor区的值，会减小YGC的次数，但由于空间变大理论上也会相应的增加YGC的时间，不过由于新生代本身就很小（才36M）这点儿变化可以忽略掉。实际的监控值显示YGC的时间在4-5ms之间。是可以接受范围。

SurvivorRatio 这个值还得在仔细考虑下,有待优化中

网上某个牛人的配置 :每天几百万pv一点问题都没有，网站没有停顿 

$JAVA_ARGS.="-Dresin.home=$SERVER_ROOT-server-Xms6000M-Xmx6000M-Xmn500M-XX:PermSize=500M-XX:MaxPermSize=500M-XX:SurvivorRatio=65536-XX:MaxTenuringThreshold=0-Xnoclassgc-XX:+DisableExplicitGC-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=0-XX:+CMSClassUnloadingEnabled-XX:-CMSParallelRemarkEnabled-XX:CMSInitiatingOccupancyFraction=90-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:log/gc.log";

说明一下， -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0就是去掉了救助空间；

-Xnoclassgc禁用类垃圾回收，性能会高一点；

-XX:+DisableExplicitGC禁止System.gc()，免得程序员误调用gc方法影响性能；

-XX:+UseParNewGC，对年轻代采用多线程并行回收，这样收得快；

带CMS参数的都是和并发回收相关的，不明白的可以上网搜索；

CMSInitiatingOccupancyFraction，这个参数设置有很大技巧，基本上满足(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn就不会出现promotion failed。在我的应用中Xmx是6000，Xmn是500，那么Xmx-Xmn是5500兆，也就是年老代有5500兆，CMSInitiatingOccupancyFraction=90说明年老代到90%满的时候开始执行对年老代的并发垃圾回收（CMS），这时还剩10%的空间是5500*10%=550兆，所以即使Xmn（也就是年轻代共500兆）里所有对象都搬到年老代里，550兆的空间也足够了，所以只要满足上面的公式，就不会出现垃圾回收时的promotion failed；

SoftRefLRUPolicyMSPerMB这个参数我认为可能有点用，官方解释是softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap，我觉得没必要等1秒；

-Xmx4000M-Xms4000M-Xmn600M-XX:PermSize=500M-XX:MaxPermSize=500M-Xss256K-XX:+DisableExplicitGC-XX:SurvivorRatio=1-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:+CMSParallelRemarkEnabled-XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=0-XX:+CMSClassUnloadingEnabled-XX:LargePageSizeInBytes=128M-XX:+UseFastAccessorMethods-XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=80-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:log/gc.log

改进方案：

上面方法不太好，因为没有用到救助空间，所以年老代容易满，CMS执行会比较频繁。我改善了一下，还是用救助空间，但是把救助空间加大，这样也不会有promotion failed。
具体操作上，32位Linux和64位Linux好像不一样，64位系统似乎只要配置MaxTenuringThreshold参数，CMS还是有暂停。为了解决暂停问题和promotion failed问题，最后我设置-XX:SurvivorRatio=1 ，并把MaxTenuringThreshold去掉，这样即没有暂停又不会有promotoin failed，而且更重要的是，年老代和永久代上升非常慢（因为好多对象到不了年老代就被回收了），所以CMS执行频率非常低，好几个小时才执行一次，这样，服务器都不用重启了。

某网友:

$JAVA_ARGS.="-Dresin.home=$SERVER_ROOT-server-Xmx3000M-Xms3000M-Xmn600M-XX:PermSize=500M-XX:MaxPermSize=500M-Xss256K-XX:+DisableExplicitGC-XX:SurvivorRatio=1-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:+CMSParallelRemarkEnabled-XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=0-XX:+CMSClassUnloadingEnabled-XX:LargePageSizeInBytes=128M-XX:+UseFastAccessorMethods-XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=70-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:log/gc.log";

64位jdk参考设置，年老代涨得很慢，CMS执行频率变小，CMS没有停滞，也不会有promotion failed问题，内存回收得很干净

时间： 2024-07-28 18:25:36

JVM生产环境参数实例及分析[转]的相关文章

[转]JVM系列四:生产环境参数实例及分析【生产环境实例增加中】

原文地址:http://www.cnblogs.com/redcreen/archive/2011/05/05/2038331.html java application项目(非web项目) 改进前: -Xms128m-Xmx128m-XX:NewSize=64m-XX:PermSize=64m-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=78-XX:ThreadStackSize=128-Xloggc:logs/gc.log

JVM系列四:生产环境参数实例及分析【生产环境实例增加中】

java application项目(非web项目) 改进前: -Xms128m-Xmx128m-XX:NewSize=64m-XX:PermSize=64m-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=78-XX:ThreadStackSize=128-Xloggc:logs/gc.log-Dsun.rmi.dgc.server.gcInterval=3600000-Dsun.rmi.dgc.client.gcInterva

生产环境参数实例及分析【生产环境实例增加中】

$JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xmx3000M -Xms3000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseC

Hadoop初学指南(6)--MapReduce的简单实例及分析

本文在上一节的基础上通过一个简单的MR示例对MapReduce的运行流程进行分析. 假设有两行数据,分别是hello you,hello me,我们要统计其中出现的单词以及每个单词出现的次数. 所得的结果为 hello   2 you     1 me      1 (1)大致运行流畅 1.解析成2个<k,v>,分别是<0, hello you><10, hello me>.调用2次map函数. 2.执行map任务 3.map输出后的数据是:<hello,1>

Android中的消息处理实例与分析

Android中的消息处理实例与分析 摘要 本文介绍了Android中的消息处理机制,给出了Android消息处理中的几个重点类Handler.Message.MessageQueue.Looper.Runnable.Thread的详细介绍,提供了两个消息处理的实例代码,并深入分析了使用Android消息机制应该遵循的几个原则. 阅读本文的收获 在具有java基础的情况下,Android的学习比较轻松,很多人在没有深刻了解Android消息处理机制的背景下,已经能够开发出可用的app,很多人开始

电脑声卡维修经验和实例完全分析

电脑声卡维修经验和实例完全分析 声卡无法"即插即用" 1．检查声卡跳线是否正确.例如,一块联讯OPTI931声卡,有一说明书上没有的隐含跳线JP3,短路即为PnP,开路时Windows 95认不出声卡,但出厂时默认为开路! 2．如果你的声卡号称PnP,但Windows95就是不认怎么办?像以前很难安装的007声卡,解决方法很简单:假设安装前操作系统是DOS,先安装DOS下的声卡驱动再进行Windows 95的安装,在安装中间提示"本机即插即用设备"时选择"

通过实例来分析I2C基本通信协议

本文旨在用最通俗易懂的方式,让大家明白I2C通信的过程究竟是怎么回事. I2C起源于飞利浦公司的电视设计,但之后朝通用路线发展,各种电子设计都有机会用到I2C 总的来说,I2C可以简单归纳为,两根线,一个时钟线,一个数据线:一个总线上,一个主控,多个从设备.I2C的作用当然是用来传输数据,它的最大特点就是仅仅用了2根线,可以完成对总线上多个从设备的有序通信,这就依赖于其通信协议了. 主控相当于I2C的大脑,每一次读写操作都必须是主控发起的.这样就保证了多个从属设备间是无法直接通信的,这样就防止了

JVM 分代GC策略分析

JVM 分代GC策略分析 我们以Sun HotSpot VM来进行分析,首先应该知道,如果我们没有指定任何GC策略的时候,JVM默认使用的GC策略.Java虚拟机是按照分代的方式来回收垃圾空间,我们应该知道,垃圾回收主要是针对堆(Heap)内存进行分代回收,将对内存可以分成新生代(Young Generation).年老代(Tenured Generation)和永久代(Permanent Generation)三个部分. 分代GC 分代GC包括如下三代: 新生代(Young Generatio

jvm虚拟机（一）：jvm内存溢出问题的分析与解决

??学习一下java虚拟机系列,之一 添加运行参数-XX:+HeapDumpOnOutOfMemoryError -Xms30m -Xmx30m -XX:+HeapDumpOnOutOfMemoryError 这个参数会生成堆栈快照,用于定位异常 模拟内存溢出的场景,简单代码: 123456789101112131415161718192021222324252627282930313233 package top.alertcode.demo.jvm; import java.util.Arr