JVM parameter optimization practice xx

Http://www.cjsdn.net/post/print? Bid = 62 and ID = 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 usually does not appear to be a major problem within 24 hours after resin is started. The website can be accessed normally. However, it is found that full GC is executed more and more frequently in nearly 24 hours, there is a full GC every three minutes. Every full GC system will pause for about 6 seconds. As a website, it may be too long for users to wait for 6 seconds, so this method needs to be improved. Maxtenuringthreshold = 7 indicates that if an object has been moved 7 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 seconds. It may also be because the parameter settings are not good enough. maxgcpausemillis indicates the maximum pause time of GC. The system is normal when resin is just started and full GC is not executed, but once full GC is executed, maxgcpausemillis is useless at all. The pause time may exceed 20 seconds. I don't care about what will happen in the future. 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: bytes = 7-XX: gctimeratio = 19-xnoclassgc-xloggc: log/GC. log-XX: + printgcdetails-XX: + printgctimestamps-XX: + usecmscompactatfullcollection-XX: cmsfullgcsbeforecompaction = 0 ";
Although this configuration will not be able to connect to the system for 10 seconds, the system will be restarted for about 3 hours and will not be able to connect to the system for 5 seconds every few minutes. Check the GC. log, it is found that there is a promotion failed error when executing parnewgc, which leads to the execution of full GC, resulting in system pause and frequent, once every few minutes, so it has to be improved. Usecmscompactatfullcollection is used to compress the memory after full GC is executed.

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: Signature = 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 recovery is better and the performance is relatively high. As long as the promotion failed error can be solved when parnewgc (parallel recovery of young generation) is solved, it is easy to handle it. I have checked many articles, the cause of the promotion failed error is that the CMS cannot be recycled (by default, the CMS will be executed only when it accounts for about 90% of the old generation ), the old generation does not have enough space for GC to move some living objects from the young generation to the old generation, so full GC is executed. Cmsinitiatingoccupancyfraction = 70 indicates that CMS is executed when the old generation accounts for about 70% of the total, so that full GC will not occur. 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: Export vorratio = 8-XX: maxtenuringthreshold = 7-XX: gctimeratio = 19-xnoclassgc-XX: + disableexplicitgc-XX: + useparnewgc-XX: + useconcmarksweepgc-XX: + response-XX: cmsfullgcsbeforecompaction = 0-XX: + cmsclassunloadingenabled-XX:-cmsparallelremarkenabled-XX: Signature = 70-XX: Signature = 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.

If the parameters are not clear, you can check them online. I think the most important parameters are-XMS-xmx-xmn maxtenuringthreshold gctimeratio useconcmarksweepgc cmsinitiatingoccupancyfraction softreflrupolicymspermb.