JVM Series Four: Examples of production environment parameters and analysis "increase in production environment instances"

Java Application project (non-Web project)

Before improvement:

-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

Problem:

1. PermSize setting is small and easy to reach alarm range (0.8)
2. Without setting maxpermsize, heap growth can bring additional stress.
3. newsize larger, old Gen 64m remaining space, on the one hand may bring the old area easy to grow to the alarm range (monitoring data display oldgenused long-term around 50m, close to 78%, easy to appear full GC), on the other hand also exists promontion Fail risk

After improvement:

-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

Modify point:

1. PermSize and MaxPermSize are set to 80, on the one hand to avoid the non heap warn (alarm threshold 0.8 non-memory generally occupy up to 60M), on the one hand to avoid the pressure of the heap expansion
2. By setting xmn=24m and Survivorratio=1, the Eden area =from space=to space=8m, lowering the Eden area size, reducing YGC time (down to 3-4ms), At the same time, by setting maxtenuringthreshold=20, the old Gen grew very slowly. The problem is that the number of YGC has increased significantly.
3. The benefits of other parameter optimizations are shown in the JVM parameter settings

Once again improved

-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

Modify point:

On the above basis, adjust the xmn size to 36M, set the cmsinitiatingoccupancyfraction=73.

The size of the Dden area and the survivor area are increased to 12M, and by cmsinitiatingoccupancyfraction calculation formula, the value of 73 is calculated to avoid promotion faild problem, Simultaneously satisfies the heap memory monitoring alarm value at 80%: Memory size 128m*80%=102.4m 102.4m-36m=66.4m (Laosheng generation reaches this value alarm) Laosheng generation reaches 67.15M (92m*0.73) will occur full GC,       Therefore, when the Laosheng generation size reaches 66.4M, that is warn alarm will likely appear full GC. Increases the value of Eden and Survivor area, will reduce the number of YGC, but because the space becomes larger theoretically will increase the YGC time correspondingly, but because the Cenozoic itself is very small (only 36M) craved changes can be ignored. The actual monitoring value shows the YGC time between 4-5ms.      is acceptable to the range. The value of Survivorratio is still under careful consideration and needs to be optimized. Online A cow's configuration: Millions of PV a day no problem, the site did not pause

$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
";

Explain,-xx:survivorratio=65536-xx:maxtenuringthreshold=0 is to remove the rescue space;

-XNOCLASSGC Disable garbage collection, performance will be a bit higher;

-XX:+DISABLEEXPLICITGC prohibit System.GC (), lest the programmer mistakenly call GC method to affect performance;

-XX:+USEPARNEWGC, the young generation of multi-threaded parallel recovery, so close;

With the CMS parameters are related to concurrent recycling, do not understand the Internet to search;

Cmsinitiatingoccupancyfraction, this parameter setting has great skill, basically satisfies (xmx-xmn) * (100-cmsinitiatingoccupancyfraction)/100>= XMN will not appear promotion failed. In my application xmx is the 6000,XMN is 500, then xmx-xmn is 5500 trillion, that is, the old generation has 5500 trillion, Cmsinitiatingoccupancyfraction=90 explained the old generation to 90% When the full time began to implement the old generation of garbage collection (CMS), then there is still 10% of the space is 5500*10%=550 trillion, so even if xmn (that is, the young generation of 500 trillion) all the objects are moved to the old generation, 550 trillion of space is enough, so as long as the above formula is satisfied, There will be no garbage collection when the promotion failed;

SOFTREFLRUPOLICYMSPERMB This parameter I think might be a bit of a use, the official explanation is 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, and I don't think it's necessary to wait 1 seconds;

-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

Improvement Program:

The above method is not very good, because there is no use to save space, so the old generation easily full, CMS execution will be more frequent. I improved a bit, or to save space, but to increase the space to save, so there will not be promotion failed.
Specifically, 32-bit Linux and 64-bit Linux do not seem to be the same, the 64-bit system appears to be configured as long as the Maxtenuringthreshold parameter, the CMS still has a pause. In order to solve the suspension problem and promotion failed problem, finally I set up-xx:survivorratio=1, and maxtenuringthreshold removed, so that there is no pause and there will be no promotoin failed, And more importantly, the old generation and the permanent generation rise very slowly (because many objects can not be recycled in the old generation), so the CMS execution frequency is very low, several hours to execute once, so that the server does not have to restart.

A netizen:

$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-bit JDK reference settings, the aging generation is slow, CMS execution frequency is smaller, CMS does not stall, there will be no promotion failed problem, memory recovery is very clean reference: JVM parameter tuning, no stagnation practice

JVM Series Four: Examples of production environment parameters and analysis "increase in production environment instances"