Shulou(Shulou.com)06/03 Report--

In this issue, Xiaobian will bring you several strategies for JVM tuning. The article is rich in content and analyzed and described from a professional perspective. After reading this article, I hope you can gain something.

JVM parameter tuning is a headache problem, which may have something to do with the application. What others say may not work for themselves. The following is some of my practical experience in JVM tuning, hoping to help readers, environment LinuxAS4, resin2.1.17, JDK6.0, 2CPU, 4G memory,dell2950 server.

JVM tuning

1: Serial garbage collection for JVM tuning

That is, the default configuration takes 153 seconds to complete 100,000 requests. JVM parameters are configured as follows:

$JAVA_ARGS.= "-Dresin.home=$SERVER_ROOT-server -Xms2048M-Xmx2048M-Xmn512M-XX:PermSize=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 have a big problem within 24 hours of resin startup, and the website can be accessed normally, but looking at the logs, it is found that FullGC is executed more and more frequently in close to 24 hours, about once every 3 minutes, and each time the FullGC system will pause for about 6 seconds. As a website, users may wait 6 seconds too long, so this method needs to be improved. MaxTenuringThreshold=7 means that an object will be put into the old generation if it has not been recycled after 7 moves in the rescue space, GCTimeRatio=19 means that java can use 5% of the time to do garbage collection, 1/(1+19)=1/20=5%.

2: Parallel Recycling for JVM Tuning

It takes 117 seconds to complete 100,000 requests. The configuration is as follows:

$JAVA_ARGS.= "-Dresin.home=$SERVER_ROOT-server-Xmx2048M -Xms2048M-Xmn512M-XX:PermSize=256M-XX:MaxPermSize=256M -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";

Parallel recovery I tried a variety of combinations of configurations, it seems that nothing useful, resin starts about 3 hours will stop, time more than 10 seconds. MaxGCPauseMillis indicates GC*** pause time. The system is normal when resin is just started and FullGC has not been executed. However, once FullGC is executed, MaxGCPauseMillis not used at all. The pause time may exceed 20 seconds. I no longer care what happens after that. Restart resin quickly and try other recovery strategies.

III: Concurrent Recycling of JVM Tuning

It takes 60 seconds to complete 100,000 requests, almost twice as fast as parallel recycling, and 2.5 times the performance of the default recycling strategy. The configuration is as follows:

$JAVA_ARGS.= "-Dresin.home=$SERVER_ROOT-server -Xms2048M-Xmx2048M-Xmn512M-XX:PermSize=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 will not appear 10 seconds can not connect the situation, but the system restarts about 3 hours, every few minutes there will be 5 seconds can not connect the situation, check gc.log, found in the execution of ParNewGC when there is a promotionfailed error, thus turning to the execution of FullGC, causing the system to stop, and will be very frequent, every few minutes, so still have to improve. UseCMSCompactAtFullCollection is a table to clean up and compress memory after FullGC is executed, so as to avoid memory fragmentation. CMSFullGCsBeforeCompaction=N indicates that memory compression is executed after N FullGC executions.

IV: Incremental Recycling of JVM Tuning

It takes 171 seconds to complete 100,000 requests, which is too slow. The configuration is as follows:

$JAVA_ARGS.= "-Dresin.home=$SERVER_ROOT-server -Xms2048M-Xmx2048M-Xmn512M-XX:PermSize=256M -XX:MaxPermSize=256M-XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19-Xnoclassgc-Xloggc:log/gc.log -XX:+PrintGCDetails-XX:+PrintGCTimeStamps-Xincgc";

It seems that the recycling is not too clean, and it also has a large impact on performance, not worth trying.

5: I-CMS pattern of JVM tuning concurrent recycling

It's about the same as incremental recycling, and it takes 170 seconds to complete 100,000 requests. The configuration is as follows:

$JAVA_ARGS.= "-Dresin.home=$SERVER_ROOT-server -Xms2048M-Xmx2048M-Xmn512M-XX:PermSize=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";

Using the parameters recommended by sun, the recovery effect is not good, there is still a pause, within a few hours there will be frequent pauses, what sun recommended parameters, still do not work.

VI: Incremental low-pause collectors tuned by JVM

It takes 153 seconds to complete 100,000 requests. The configuration is as follows:

$JAVA_ARGS.= "-Dresin.home=$SERVER_ROOT-server -Xms2048M-Xmx2048M-Xmn512M-XX:PermSize=256M -XX:MaxPermSize=256M-XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19-Xnoclassgc-Xloggc:log/gc.log -XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+UseTrainGC";

The configuration effect is not good, affecting performance, so did not try.

Seven: In contrast, concurrent recovery is better, performance is relatively high, as long as you can solve ParNewGC (parallel recovery of young generation) when the promotionfailed error is easy to do, check a lot of articles, found that the reason for the promotionfailed error is CMS too late to recover (CMS default in the old generation accounted for about 90% will be executed), the old generation and there is not enough space for GC to move some live objects from the young generation to the old generation, so FullGC is executed. CMSInitiatingOccupancyFraction=70 indicates that CMS starts when the older generation accounts for about 70%, so that FullGC does not occur. SoftRefLRUPolicyMSPerMB This parameter is also what I think is more useful. The official explanation is softlyreachableobjectswill remain aliveforsomeamount of time after the last time.

theywerereferenced.Thedefaultvalueisonesecondo

f life time per free me a baby tein the heap, I didn't think it was necessary to wait 1 second, so set it to 0. configured as follows

$JAVA_ARGS.= "-Dresin.home=$SERVER_ROOT-server-Xms2048M -Xmx2048M-Xmn512M-XX:PermSize=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";

The above configuration memory rise is very slow, almost no pause phenomenon within 24 hours, the longest only stagnation of 0.8s, ParNewGC is executed every 30 seconds or so, each recovery is about 0.2 seconds, it seems that the problem should be temporarily solved.

Parameters do not understand the Internet can check, I think the more important parameters are:

-Xms-Xmx-XmnMaxTenuringThresholdGCTimeRatioUse

ConcMarkSweepGCCMSInitiatingOccupancyFractionSoftRefLRUPolicyMSPerMB

JVM parameters configured in eclipse:-Xmx1024M-Xms1000M-server-XX:PermSize=64M-XX:MaxPermSize=128m

The above is what are the several strategies for JVM tuning shared by Xiaobian. If you happen to have similar doubts, you may wish to refer to the above analysis for understanding. If you want to know more about it, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.