Remember the JVM tuning trip (fight full GC)

As the saying goes, the "deep understanding of the JVM" was also specially organized notes, and now use the ~

Note http://www.cnblogs.com/syjkfind/p/3901774.html

The "Symptoms" user action data is always stuck during export, and the background memory-occupied timer task occurs. JVM parameters are not affixed, more common and relatively reasonable.

Ideas

Check GC log is happening full Gc,tomcat log fragmented there are many exception.

In addition, with the knowledge of the code, the log at the same time at the time of the trigger displays a query that is executing a large amount of data and is loaded into the JVM, with many method calls and temporary variables.

Analysis

1.minor GC is very frequent, but the time is short so the problem is not big, the trigger reason is basically the application space failure.

2. Occasional System.GC (), time is about 1 minutes. There is no explicit call in the code, which is basically determined to be triggered by the monitor RMI access. You can add parameters to disable-XX:+DISABLEEXPLICITGC.

3. There are often promotion failed, that is, in the minor GC when the young generation of the survival area of the lack of space to enter the old age, the old age and lack of space and trigger full GC. The time is about 3 minutes. One way to solve this problem is to increase the survival area, and the other is to remove the survival zone and increase the old age. The relevant parameters are generally:

-xx:survivorratio=32 Survival area divided by the ratio of Eden area, the survival zone has from and to two, so this means that a single survival area of the younger generation of 1/34;

-xx:oldsize=60m old age size;

-xx:maxtenuringthreshold=15 is the number of times minor GC survived after the young generation of objects will be promoted to the old age.

4. There are often concurrent mode failure, that is, the old age in the implementation of the CMS space is not enough, this will become the serial of older collectors resulting in a longer pause. The time is about 5 minutes. The problem may be caused by too much floating garbage, possibly the CMS collector itself taking up heap space, or perhaps too many fragments of the old age, but all of the features of the CMS collector. The relevant configuration is generally:

-xx:cmsinitiatingoccupancyfraction=80 that the old age of 80% trigger the CMS (full GC), the height of the GC is relatively reduced, the lower is more fast processing full GC;

-xx:usecmscompactatfullcollection or-xx:cmsfullgcsbeforecompaction=5 is defragmentation before or after the full GC.

5. There is also an interesting article, too much too long exception will lead to promotion failed

Http://www.th7.cn/Program/java/201511/685711.shtml

May be quite in line with our scene, there is no operation and maintenance permission, next time you can consider looking for operations to dump a analysis of the object.

Previously, in order to trace the error closed "fast throw"-xx:-O mitstacktraceinfastthrow that is repeated exception will not use a static instance of no stack information to replace, this should weigh.

Solution

Creating many objects for younger generations? Big objects lead to the old age? Floating garbage (the CMS continues to produce temporary objects) or fragments of the old age?

Tuning how much can be improved, but it seems that the code itself is more problematic, I'm afraid the allocation of more memory is not enough to eat . For example, there is no more sophisticated first-level cache two cache, such as often rough to load tens of thousands of records, have not done paging, there is more deep to do the cut plane to trigger the asynchronous service to fill the asynchronous service queue. Initially enjoy the convenience of the framework and consider less design, and now you have to start technical debt ~

Fortunately for a limited time, we have a simple and brutal way to alleviate these problems: Add the server, the big task stripping out ~

In the medium and long term, in the premise of not changing the existing framework, rectification exception, rectification business code to do paging, packaging database paging query framework, the transformation of database Layer two cache (cluster-wide cache) will be more effective measures.

The longer-term affirmation is to return to the spring system mainstream framework, and further into the service of the ... But that's almost something the business code again.

Regression theme If it is tuning to solve the problem, it is best to dump to do more in-depth analysis. Subjectively it seems that enabling fast-throw, post-GC defragmentation, and increasing the survival area should be a more targeted adjustment, while a more granular analysis is needed for cmsinitiatingoccupancyfraction and the detailed configuration of each stage of the CMS.

Remember the JVM tuning trip (fight full GC)