JVM 参数设置

 

JVM 参数设置

参考文献：http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

 

某个大流量网站中JVM参数设置如下：

 

 

 

-Xms10000M -Xmx10000M -Xmn5000M

-Xss128k

-XX:PermSize=256m

-XX:MaxPermSize=512m

-XX:+UseParNewGC

-XX:ParallelGCThreads=8                       默认开启回收线程数（并行GC线程数+3）/4

-XX:SurvivorRatio=6

-XX:TargetSurvivorRatio=90

-XX:MaxTenuringThreshold=30                       控制对象在新生代存活的最大次数

-XX:+UseConcMarkSweepGC

-XX:+UseCMSCompactAtFullCollection             下面两个参数，由于CMS会产生垃圾浮点，所以每执行5次full GC

-XX:CMSFullGCsBeforeCompaction=5                内存就进行整理

-XX:CMSInitiatingOccupancyFraction=55        旧生代使用55%的比例触发full GC

-XX:SoftRefLRUPolicyMSPerMB=0                 

-XX:CMSIncrementalSafetyFactor=20            ？？？？？？？？？？？？？？

-XX:+CMSIncrementalMode                          ？？？？？？？？？？？？？

-XX:+UseCMSInitiatingOccupancyOnly         禁止hotspot自行触发CMS GC

-XX:+PrintGCDetails -XX:+PrintGCTimeStamp

考虑的是持久代的GC也可以设置：-XX:+CMSPermGenSweepingEnabled,-XX:+CMSClassUnloadingEnabled

 

 

额外参数需要考虑的：

-XX:+DisableExplicitGC禁止System.gc()

 

-XX: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秒； 

 

如果在CMS算法中配置了: -XX:+UseAdaptiveSizePolicy 表示堆中各个区的比例由JVM自己分配即动态变化

-XX:+DisableExplicitGC禁止System.gc()

 

CMS算法

 

优点：

• 在Old进行回收时，对应用的暂停时间非常短，适合对latency要求高的应用

缺点：

• 内存碎片和浮动垃圾
• Old区内存分配效率低
• 回收的整个耗时比较长
• 和应用争取CPU

二、内存回收触发机制

 

1、YGC   eden空间不足

2、CMS GC

• Old区域使用达到一定的比例，默认是92%
• 配置了CMSClassunloadingEnabled，且Perm 区域使用达到一定比例，默认92%
• hotspot自己根据估计决定是否要触发
• 在配置ExplicitGCInvokesConcurrent的情况下调用了System.gc

Full GC如果出现了Promotion failed 或Concurrent Mode Failure 时，GC采用 serial MSC

promotion failed，(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn

 

三、对于CMS算法中增量模式的解释

 

-XX:+CMSIncrementalMode

 

请看原文的意思：

The concurrent collector can be used in a mode in which the concurrent phases are done 
incrementally. Recall that during a concurrent phase the garbage collector thread is using a processor. 
The incremental mode is meant to lessen the impact of long concurrent phases by periodically stopping
 the concurrent phase to yield back the processor to the application. This mode 
(referred to here as “i-cms”) divides the work done by concurrently by the collector into small chunks
 of time which are scheduled between young generation collections. This feature is useful when 
applications that need the low pause times provided by the concurrent collector are run on machines 
with small numbers of processors (e.g., 1 or 2).

The concurrent collection cycle typically includes the following steps:

    stop all application threads; do the initial mark; resume all application threads

    do the concurrent mark (uses one procesor for the concurrent work)

    do the concurrent pre-clean (uses one processor for the concurrent work)

    stop all application threads; do the remark; resume all application threads

    do the concurrent sweep (uses one processor for the concurrent work)

    do the concurrent reset (uses one processor for the concurrent work)

Normally, the concurrent collector uses one processor for the concurrent work for the entire 
concurrent mark phase, without (voluntarily) relinquishing it. Similarly, one processor is used for the
 entire concurrent sweep phase, again without relinquishing it. This processor utilization can be too
 much of a disruption for applications with pause time constraints, particularly when run on systems 
with just one or two processors. i-cms solves this problem by breaking up the concurrent phases into
 short bursts of activity, which are scheduled to occur mid-way between minor pauses.

I-cms uses a "duty cycle" to control the amount of work the concurrent collector is allowed to do 
before voluntarily giving up the processor. The duty cycle is the percentage of time between young 
generation collections that the concurrent collector is allowed to run. I-cms can automatically compute
 the duty cycle based on the behavior of the application (the recommended method), or the duty cycle
 can be set to a fixed value on the command line.

 

 

The following command-line options control i-cms (see below for recommendations for an initial set of 
options):

-XX:+CMSIncrementalMode default: disabled

This flag enables the incremental mode. Note that the concurrent collector must be enabled (with 
-XX:+UseConcMarkSweepGC) for this option to work.

-XX:+CMSIncrementalPacing default: disabled

This flag enables automatic adjustment of the incremental mode duty cycle based on statistics 
collected while the JVM is running.

-XX:CMSIncrementalDutyCycle=<N> default: 50

This is the percentage (0-100) of time between minor collections that the concurrent collector is
 allowed to run. If CMSIncrementalPacing is enabled, then this is just the initial value.

-XX:CMSIncrementalDutyCycleMin=<N> default: 10

This is the percentage (0-100) which is the lower bound on the duty cycle when CMSIncrementalPacing 
is enabled.

-XX:CMSIncrementalSafetyFactor=<N> default: 10

This is the percentage (0-100) used to add conservatism when computing the duty cycle.

-XX:CMSIncrementalOffset=<N> default: 0

This is the percentage (0-100) by which the incremental mode duty cycle is shifted to the right within 
the period between minor collections.

-XX:CMSExpAvgFactor=<N> default: 25

This is the percentage (0-100) used to weight the current sample when computing exponential 
averages for the concurrent collection statistics.

5.4.9.2 Recommended Options for i-cms

When trying i-cms, we recommend the following as an initial set of command line options:

-XX:+UseConcMarkSweepGC \

-XX:+CMSIncrementalMode \

-XX:+CMSIncrementalPacing \

-XX:CMSIncrementalDutyCycleMin=0 \

-XX:+CMSIncrementalDutyCycle=10 \

-XX:+PrintGCDetails \

-XX:+PrintGCTimeStamps \

-XX:-TraceClassUnloading

 所以要慎重的使用该参数，不要使用JVM自己收集JVM信息去触发GC，自己使用过该参数，深有体会，full gc不可控。