Tuning JVM Parameters

Tuning JVM Parameters

JVM parameter tuning is a very headache, it may be related to the application, the following is some of my tuning experience, I hope to be helpful to readers, environment linuxas4,resin2.1.17,jdk6.0,2cpu,4g memory, dell2950 server.

A: Serial garbage collection, also is the default configuration, complete 100,000 request time 153 seconds, the JVM parameters are configured as follows
$JAVA _args. = "-dresin.home= $SERVER _root-server-xms2048m-xmx2048m-xmn512m-xxermsize=256m-xx:maxpermsize=256m-xx: Maxtenuringthreshold=7-xx:gctimeratio=19-xnoclassgc-xloggc:log/gc.log-xx:+printgcdetails-xx:+printgctimestamps ";

This configuration generally does not seem to be a major problem within 24 hours of resin startup, the site can be accessed normally, but the view log found that, nearly 24 hours, full GC execution more and more frequently, about every 3 minutes there is a full GC, each time the full GC system will pause for about 6 seconds, As a Web site, the user waiting for 6 seconds is probably too long, so this approach needs to be improved. Maxtenuringthreshold=7 indicates that an object that is moved 7 times in the rescue space has not yet been recycled into the old generation, gctimeratio=19 that Java can use 5% of the time to do garbage collection, 1/(1+19) =1/20=5%.

Second: Parallel recovery, complete 100,000 request spents 117 seconds, configured as follows:
$JAVA _args. = "-dresin.home= $SERVER _root-server-xmx2048m-xms2048m-xmn512m-xxermsize=256m-xx:maxpermsize=256m- XNOCLASSGC-XLOGGC:LOG/GC.LOG-XX:+PRINTGCDETAILS-XX:+PRINTGCTIMESTAMPS-XX:+USEPARALLELGC-XXARALLELGCTHREADS=20- XX:+USEPARALLELOLDGC-XX:MAXGCPAUSEMILLIS=500-XX:+USEADAPTIVESIZEPOLICY-XX:MAXTENURINGTHRESHOLD=7-XX: Gctimeratio=19 ";

Parallel recycling I tried a variety of combination configurations, it doesn't seem to work, resin start 3 hours or so will be paused, time more than 10 seconds. It is also possible that the parameter settings are not good enough, Maxgcpausemillis represents the GC maximum pause time, the system is normal when resin has not executed full GC, but once full gc,maxgcpausemillis is executed, The pause time may be more than 20 seconds, after what will happen I no longer care, hurriedly restart resin, try other recycling strategy.

Three: Concurrent recovery, complete 100,000 request time 60 seconds, more than the parallel collection of nearly one times, is the default recovery policy performance of 2.5 times times, configured as follows:
$JAVA _args. = "-dresin.home= $SERVER _root-server-xms2048m-xmx2048m-xmn512m-xxermsize=256m-xx:maxpermsize=256m-xx: +useconcmarksweepgc-xx:maxtenuringthreshold=7-xx:gctimeratio=19-xnoclassgc-xloggc:log/gc.log-xx:+ Printgcdetails-xx:+printgctimestamps-xx:+usecmscompactatfullcollection-xx:cmsfullgcsbeforecompaction=0 ";

Although this configuration does not occur 10 seconds, but the system restarts 3 hours or so, every few minutes there will be 5 seconds, see Gc.log, found in the execution of PARNEWGC there is a promotion failed error, thereby turning to perform full GC, Cause the system to stop, and it will be very frequent, every few minutes there is a time, so it has to improve. Usecmscompactatfullcollection is a table that performs a full GC to compress memory after it is executed, so that memory fragmentation is not generated, cmsfullgcsbeforecompaction=n indicates that memory compression is performed after N-Times full GC.

Four: Incremental recovery, complete 100,000 request spents 171 seconds, too slow, configured as follows
$JAVA _args. = "-dresin.home= $SERVER _root-server-xms2048m-xmx2048m-xmn512m-xxermsize=256m-xx:maxpermsize=256m-xx: Maxtenuringthreshold=7-xx:gctimeratio=19-xnoclassgc-xloggc:log/gc.log-xx:+printgcdetails-xx:+printgctimestamps -XINCGC ";

It seems that recycling is not too clean, but also has a big impact on performance, not worth trying.

V: The I-CMS mode of concurrent recovery, similar to incremental recovery, takes 170 seconds to complete 100,000 request.
$JAVA _args. = "-dresin.home= $SERVER _root-server-xms2048m-xmx2048m-xmn512m-xxermsize=256m-xx:maxpermsize=256m-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 ";

The use of sun recommended parameters, recovery effect is not good, so there is a pause, within a few hours will be frequent pauses, what sun recommended parameters, so it does not work.

Six: Incremental low pause collector, what is also called train recycling, do not know which department, complete 100,000 request spents 153 seconds
$JAVA _args. = "-dresin.home= $SERVER _root-server-xms2048m-xmx2048m-xmn512m-xxermsize=256m-xx:maxpermsize=256m-xx: Maxtenuringthreshold=7-xx:gctimeratio=19-xnoclassgc-xloggc:log/gc.log-xx:+printgcdetails-xx:+printgctimestamps -XX:+USETRAINGC ";

This configuration effect is not good, affect performance, so did not try.

Seven: In contrast, it is better to recycle, the performance is relatively high, as long as can solve PARNEWGC (parallel collection of young generation) when the promotion failed error is all good to do, check a lot of articles, found that the cause of promotion failed error is the CMS is too late to recycle (CMS default in the old generation accounted for 90% The old generation does not have enough space for the GC to move some live objects from the young generation to the old generation, so perform full GC. Cmsinitiatingoccupancyfraction=70 says that when the old generation takes up about 70%, it starts executing the CMS so that no full GC is present. SOFTREFLRUPOLICYMSPERMB This parameter is also I think more useful, the official explanation is softly reachable objects would remain alive for some amount of time after the LA St 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, so set it to 0. Configured as follows

$JAVA _args. = "-dresin.home= $SERVER _root-server-xms2048m-xmx2048m-xmn512m-xxermsize=256m-xx:maxpermsize=256m-xx: SURVIVORRATIO=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 ";

Above this configuration memory rise very slowly, 24 hours, almost no pauses, the longest only stalled 0.8s,parnew GC every 30 seconds or so to execute once, each recovery about 0.2 seconds, it seems that the problem should be temporarily resolved.

Parameters do not understand the Internet can be checked, I think the more important parameters are:-xms-xmx-xmn maxtenuringthreshold gctimeratio USECONCMARKSWEEPGC Cmsinitiatingoccupancyfraction SOFTREFLRUPOLICYMSPERMB

JVM parameter Tuning