JVM Parameter Optimization

From: http://www.cjsdn.net/post/view? Bid = 62 & id = 196304 & sty = 3 & age = 0 & TPG = 1 & PPG = 1 #196304

 

JVM parameter optimization is a headache and may be related to applications. The following is my practical experience in tuning. I hope to help readers in the following: linuxas4, resin2.1.17, jdk6.0, 2 CPU, 4G memory, dell2950 server, website is http://shedewang.com

I. Serial garbage collection, which is the default configuration. It takes 0.1 million seconds to complete the 153 request. The JVM parameter configuration is as follows:
$ Java_args
. = "-Dresin. Home = $ server_root-server-xms2048m-xmx2048m-xmn512m
-XX: permsize = 256 m-XX: maxpermsize = 256 m-XX: maxtenuringthreshold = 7
-XX: gctimeratio = 19-xnoclassgc-xloggc: log/GC. Log-XX: + printgcdetails
-XX: + printgctimestamps ";
This configuration does not appear to be a major problem within 24 hours after resin is started. The website can be accessed normally.
At present, full GC is executed more and more frequently in nearly 24 hours, and there is a full GC every 3 minutes.
The GC system will pause for about 6 seconds. As a website, it may be too long for the user to wait for 6 seconds, so this method needs to be improved. Maxtenuringthreshold = 7 indicates an object
If the mobile app has not been recycled for seven times in the rescue space, it will be placed in the old generation. gctimeratio = 19 indicates that Java can use 5% of the time for garbage collection. 1/(1 + 19) = 1
/20 = 5%.

2. Parallel collection: It takes 0.1 million seconds to complete 117 requests. The configuration is as follows:
$ Java_args. ="
-Dresin. Home = $ server_root-server-xmx2048m-xms2048m-xmn512m
-XX: permsize = 256 m-XX: maxpermsize = 256 m-xnoclassgc-xloggc: log/GC. Log
-XX: + printgcdetails-XX: + printgctimestamps-XX: + useparallelgc
-XX: parallelgcthreads = 20-XX: + useparalleloldgc-XX: maxgcpausemillis = 500
-XX: + useadaptivesizepolicy-XX: maxtenuringthreshold = 7
-XX: gctimeratio = 19 ";
I have tried a variety of combined configurations for parallel collection, and it seems useless. When resin is started for about three hours, it will pause for over 10 times.
Seconds. It may also be because the parameter settings are not good enough. maxgcpausemillis indicates the maximum pause time of GC, and full has not been executed at resin startup.
The system is normal during GC, but once full
GC and maxgcpausemillis are useless at all. The pause may take more than 20 seconds. I don't care about anything afterwards. Restart resin and try other recycling policies.

3. Concurrent collection: 60 seconds after 0.1 million requests are completed, which is twice faster than parallel collection. This is 2.5 times the performance of the default collection policy. The configuration is as follows:
$ Java_args
. = "-Dresin. Home = $ server_root-server-xms2048m-xmx2048m-xmn512m
-XX: permsize = 256 m-XX: maxpermsize = 256 m-XX: + useconcmarksweepgc
-XX: maxtenuringthreshold = 7-XX: gctimeratio = 19-xnoclassgc
-Xloggc: log/GC. Log-XX: + printgcdetails-XX: + printgctimestamps
-XX: + usecmscompactatfullcollection-XX: cmsfullgcsbeforecompaction = 0 ";
This
Configuration, although not 10 seconds, but the system restarts for about 3 hours, there will be 5 seconds of failure every few minutes, view GC. log, it is found that when parnewgc is executed
Promotion failed errors, and thus turn to full execution
GC causes the system to pause and can occur frequently. It takes several minutes to improve. Usecmscompactatfullcollection is used to execute full
After GC, compress the memory to avoid memory fragmentation. cmsfullgcsbeforecompaction = n indicates that memory compression is performed after N full GC operations.

4. incremental recovery: It takes 0.1 million seconds to complete 171 requests. The configuration is as follows:
$ Java_args
. = "-Dresin. Home = $ server_root-server-xms2048m-xmx2048m-xmn512m
-XX: permsize = 256 m-XX: maxpermsize = 256 m-XX: maxtenuringthreshold = 7
-XX: gctimeratio = 19-xnoclassgc-xloggc: log/GC. Log-XX: + printgcdetails
-XX: + printgctimestamps-xincgc ";
It seems that the collection is not very clean, and it also has a great impact on the performance. It is not worth trying.

5: The I-CMS mode of concurrent recovery, and incremental recovery is almost the same, the completion of 0.1 million requests took 170 seconds.
$ Java_args
. = "-Dresin. Home = $ server_root-server-xms2048m-xmx2048m-xmn512m
-XX: permsize = 256 m-XX: maxpermsize = 256 m-XX: maxtenuringthreshold = 7
-XX: gctimeratio = 19-xnoclassgc-xloggc: log/GC. Log-XX: + printgcdetails
-XX: + printgctimestamps-XX: + useconcmarksweepgc-XX: + cmsincrementalmode
-XX: + cmsincrementalpacing-XX: cmsincrementaldutycyclemin = 0
-XX: cmsincrementaldutycycle = 10-XX:-traceclassunloading ";
Using the parameters recommended by Sun, the recovery effect is not good. There is still a pause, and frequent pauses will occur within a few hours. What sun-recommended parameters are still not good.

6. incremental low pause collector. What kind of train recycle is called? I don't know which system it belongs to. It takes 0.1 million seconds to complete the 153 request.
$ Java_args
. = "-Dresin. Home = $ server_root-server-xms2048m-xmx2048m-xmn512m
-XX: permsize = 256 m-XX: maxpermsize = 256 m-XX: maxtenuringthreshold = 7
-XX: gctimeratio = 19-xnoclassgc-xloggc: log/GC. Log-XX: + printgcdetails
-XX: + printgctimestamps-XX: + usetraingc ";
This configuration does not work well and affects performance, so I did not try it.

7:
In contrast, concurrent collection is better, and the performance is relatively high, as long as it can solve the promotion of parnewgc (parallel collection of young generation)
Failed errors are easy to handle. I checked many articles and found that they caused promotion.
The cause of the failed error is that the CMS cannot be recycled (by default, the CMS will be executed only when the old generation accounts for about 90% ), the old generation does not have enough space for GC to move some living objects from the young generation to the old generation.
So execute full
GC. Cmsinitiatingoccupancyfraction = 70 indicates that CMS is executed when the old generation accounts for about 70%, so that full
GC. Softreflrupolicymspermb is also useful in my opinion. 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, so it is set to 0. The configuration is as follows:
$ Java_args. ="
-Dresin. Home = $ server_root-server-xms2048m-xmx2048m-xmn512m
-XX: permsize = 256 m-XX: maxpermsize = 256 m-XX: Required vorratio = 8
-XX: maxtenuringthreshold = 7-XX: gctimeratio = 19-xnoclassgc
-XX: + disableexplicitgc-XX: + useparnewgc-XX: + useconcmarksweepgc
-XX: + cmspermgensweepingenabled-XX: + usecmscompactatfullcollection
-XX: cmsfullgcsbeforecompaction = 0-XX: + cmsclassunloadingenabled
-XX:-cmsparallelremarkenabled-XX: cmsinitiatingoccupancyfraction = 70
-XX: softreflrupolicymspermb = 0-XX: + printclasshistogram
-XX: + printgcdetails-XX: + printgctimestamps
-XX: + printgcapplicationconcurrenttime
-XX: + printgcapplicationstoppedtime-xloggc: log/GC. log ";
The memory usage of the above configuration is very slow, and there is almost no pause within 24 hours. The longest memory usage is only 0.8 S. The parnew GC is executed every 30 seconds, and the memory usage is collected every time for about 0.2 seconds, it seems that the problem should be solved temporarily.

Parameter
If you do not know the number, you can check it online. In my opinion, the most important parameters are-XMS-xmx-xmn maxtenuringthreshold.
Gctimeratio useconcmarksweepgc cmsinitiatingoccupancyfraction
Softreflrupolicymspermb