JVM Series 4: Production Environment Parameter instances and analysis [adding production environment instances]

Java application project (non-web project)

Before improvement:

-Xms128m
-Xmx128m
-XX: newsize = 64 m
-XX: permsize = 64 m
-XX: + useconcmarksweepgc
-XX: cmsinitiatingoccupancyfraction = 78
-XX: thread stacksize = 128
-Xloggc: logs/GC . Log 
-Dsun . RMI  . DGC  . Server  . Gcinterval = 3600000
-Dsun . RMI  . DGC . Client  . Gcinterval = 3600000
-Dsun . RMI  . Server  . Exceptiontrace = True

Problem:

1. The permsize setting is small and can easily reach the alarm range (0.8)
2. If maxpermsize is not set, increasing the heap may cause extra pressure.
3. The newsize is large, and the remaining space of the Old Gen is 64 mb. On the one hand, the old zone may easily grow to the alarm range (the monitoring data shows that the oldgenused is about 50 MB for a long time, close to 78%, it is prone to full GC), and there is also a risk of promontion fail.

After improvement:

-Xms128m
-Xmx128m
-Xmn24m
-XX: permsize = 80 m
-XX: maxpermsize = 80 m
-Xss256k
-XX: Required vorratio = 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

Modification point:

1. Both permsize and maxpermsize are set to 80. On the one hand, avoid non-heap warn (alarm threshold value 0.8 is not generally used for memory within 60 m), and on the other hand, avoid the pressure caused by heap scaling.
2. By setting xmn = 24m and kernel vorratio = 1, the Eden area = from space = to Space = 8 m reduces the size of the Eden area and the ygc time (about 3-4 ms ), at the same time, by setting maxtenuringthreshold = 20, the growth of Old Gen is very slow. The problem is that the number of ygc operations has increased significantly.
3. For the benefits of other parameter optimization and modification, see JVM parameter settings.

After further improvement

-Xms128m
-Xmx128m
-Xmn36m
-XX: permsize = 80 m
-XX: maxpermsize = 80 m
-Xss256k
-XX: Required vorratio = 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

Modification point:

Based on the above, adjust the xmn size to 36 m and set cmsinitiatingoccupancyfraction to 73.

The size of both the dden and vor areas is increased to 12 Mb. By using the cmsinitiatingoccupancyfraction formula, the value of 73 is obtained, which can avoid the promotion faild problem and meet the heap memory monitoring alarm value of 80%: memory size 128 M * 80% = 102.4 M 102.4 M-36 M = 66.4 M (the old generation reaches this value for alarm) the old generation reaches 67.15 M (92 M * 0.73) full GC will occur, so full GC may occur when the size of the old generation reaches 66.4m, that is, when the warn alarm is triggered. Increasing the values of Eden and zoovor reduces the number of ygc operations. However, due to the larger space, the time required for ygc is also increased in theory, but the new generation is very small (only 36 m) this change can be ignored. The actual monitoring value shows that the ygc time is between 4-5 ms. Is an acceptable range. The value of reverse vorratio must be carefully considered and needs to be optimized. Configuration of a cool man on the Internet: Millions of PVS per day have no problems at all, and the website has not paused

$ Java_args
. =
"
-Dresin . Home = $ Server_root
-Server
-Xms6000m
-Xmx6000m
-Xmn500m
-XX: permsize = 500 m
-XX: maxpermsize = 500 m
-XX: Required vorratio = 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
"; 

Note:-XX: Export vorratio = 65536-XX: maxtenuringthreshold = 0 means the rescue space is removed;

-Xnoclassgc: Disable class garbage collection, which improves the performance;

-XX: + disableexplicitgc: Disable system. GC () to avoidProgramThe operator mistakenly calls the GC method to affect the performance;

-XX: + useparnewgc, which adopts multi-thread parallel collection for the young generation, so as to collect fast;

The CMS parameters are related to concurrent recovery. If you do not understand them, you can search for them online;

Cmsinitiatingoccupancyfraction. this parameter is very skillful and basically satisfies (xmx-xmn) * (100-cmsinitiatingoccupancyfraction)/100> = xmn, so promotion failed will not appear. In my application, xmx is 6000 and xmn is 500, so xmx-xmn is 5500 MB, that is, there are 5500 MB in the old generation, cmsinitiatingoccupancyfraction = 90 indicates that the concurrent garbage collection (CMS) for the old generation starts when the old generation reaches 90%, and 10% of the remaining space is 5500 * 10% = 550 MB, therefore, even if all objects in the xmn (that is, the young generation has a total of 500 mb) are moved to the old generation, the space of 550 MB is sufficient, so as long as the above formula is met, there will be no promotion failed during garbage collection;

Softreflrupolicymspermb is a bit useful. 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, I don't think it is necessary to wait 1 second;

-Xmx4000m
-Xms4000m
-Xmn600m
-XX: permsize = 500 m
-XX: maxpermsize = 500 m
-Xss256k
-XX: + disableexplicitgc
-XX: Required vorratio = 1
-XX: + useconcmarksweepgc
-XX: + useparnewgc
-XX: + cmsparallelremarkenabled
-XX: + usecmscompactatfullcollection
-XX: cmsfullgcsbeforecompaction = 0
-XX: + cmsclassunloadingenabled
-XX: largepagesizeinbytes = 128 m
-XX: + usefastaccessormethods
-XX: + usecmsinitiatingoccupancyonly
-XX: cmsinitiatingoccupancyfraction = 80
-XX: softreflrupolicymspermb = 0
-XX: + printclasshistogram
-XX: + printgcdetails
-XX: + printgctimestamps
-XX: + printheapatgc
-Xloggc: log/GC . Log 

Improvement Plan:

The above method is not very good, because the rescue space is not used, so the old generation is easy to full, CMS will be executed more frequently. I improved it by using the rescue space, but increased the rescue space, so there would be no promotion failed.
In specific operations, 32-bit Linux and 64-bit Linux seem to be different. 64-bit systems seem to be suspended as long as the maxtenuringthreshold parameter is configured. In order to solve the pause and promotion failed problems, I finally set-XX: Always vorratio = 1 and remove maxtenuringthreshold. In this way, no promotoin failed will be available, and more importantly, the rise of the old and permanent generations is very slow (because many objects cannot be recycled in the old generation), so the execution frequency of CMS is very low, and it takes several hours to execute it, the server does not need to be restarted.

A netizen:

$ Java_args
. =
"
-Dresin . Home = $ Server_root
-Server
-Xmx3000m
-Xms3000m
-Xmn600m
-XX: permsize = 500 m
-XX: maxpermsize = 500 m
-Xss256k
-XX: + disableexplicitgc
-XX: Required vorratio = 1
-XX: + useconcmarksweepgc
-XX: + useparnewgc
-XX: + cmsparallelremarkenabled
-XX: + usecmscompactatfullcollection
-XX: cmsfullgcsbeforecompaction = 0
-XX: + cmsclassunloadingenabled
-XX: largepagesizeinbytes = 128 m
-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 old generation is slow, the CMS execution frequency is reduced, the CMS is not stuck, there is no promotion failed problem, the memory is recycled very clean reference: JVM parameter tuning, non-stagnant practices