** 碎片參數(shù) **
-XX:OldPLABSize=16
-XX:-ResizeOldPLAB
-XX:+PrintGCDetails
-XX:+PrintPromotionFailure
-XX:PrintFLSStatistics=1
** Concurrent mode failure **
- 設(shè)置-XX:CMSInitiatingOccupancyFraction
- 增大old區(qū)的大小
At beginning of each young GC, collector should ensure that there is enough free
memory in old space to promote aged objects from young space. Modern CMS
collector estimates size of objects to be promoted using statistics from previous
collections. If old space does not have enough free bytes to hold estimated
promotion amount, **concurrent mode failure** will be raise. Concurrent mode
failure doesn't necessary lead to Full GC, in certain cases JVM will just wait for
concurrent collection cycle to finish, but application will remain in STW pause
until young collection will be finished.
Most frequent reason for concurrent mode failure is late initiation of CMS cycle.
JVM tries to estimate amount of garbage in heap and duration of CMS cycle and
start it as late as possible to avoid wasting of CPU. Unfortunately this estimation
may be too optimistic. You can advise JVM to start CMS earlier using following
flags:
-XX:CMSInitiatingOccupancyFraction=30-XX:+UseCMSInitiatingOccupancyOnly
Setting above will force CMS cycle is more than 30% of old space is use. Second
option disables JVM heuristics, without second parameter JVM may not obey
CMS initiating occupancy fraction setting.
Normally for server type applications you would like CMS to be running
continuously. If you are experiencing **concurrent mode failure**, even though
next CMS cycle is starting right after previous, it means that CMS throughput is
just not enough. In this case you should increase size of old generation and give
CMS collector more head room to do its job. Alternatively you may try to dedicate
more CPU cores for concurrent collector, but CPU is usually even more limited
resource on modern servers than memory.
In summary, there are two reasons for **concurrent mode failure**STW pause
mentioned above, both of them can be remedied fairly easily with JVM options.
** Promotion failure **
Promotion failure is more complicated situation. CMS collector is not compacting
free memory in old space, instead it have to deal with fragmented free space (a
set of free memory chunks). It is possible, that all free bytes are scattered though
small chunks, and it is impossible to find certain amount of continuous memory to
promote particular large object, even though total number of free bytes is large
enough.
Heap fragmentation is well known problem, and there are few effective techniques
reducing fragmentation.
CMS memory manager is using separate free lists for different size of chunks.
Using these free lists, it can effectively fill small holes in fragmented memory
space with objects of exact size. This technique is known to be fairly effective
(and widely used in C/C++ memory managers). But, surprisingly, it doesn't seems
to work well for JVM in many real live situations.
