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

Today, I will talk to you about the examples and analysis of the production environment parameters in JVM. Many people may not know much about it. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

Java application project (non-web project)

Before improvement:

-Xms128m-Xmx128m-XX:NewSize=64m-XX:PermSize=64m-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=78-XX:ThreadStackSize=128-Xloggc:logs/gc.log-Dsun.rmi.dgc.server.gcInterval=3600000-Dsun.rmi.dgc.client.gcInterval=3600000-Dsun.rmi.server.exceptionTrace=true

Question:

The ◆ permsize setting is small and can easily reach the alarm range (0.8)

◆ does not have MaxPermSize set, and heap growth brings additional pressure.

The ◆ NewSize is large and the remaining space of the oldgen is 64m. On the one hand, the old area may easily grow to the alarm range (monitoring data show that the oldgenused is about 50m for a long time, close to 78%, which is prone to full gc), on the other hand, there is also a risk of promontion fail.

After improvement:

-Xms128m-Xmx128m-Xmn24m-XX:PermSize=80m-XX:MaxPermSize=80m-Xss256k-XX:SurvivorRatio=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

Modify the point:

Both ◆ PermSize and MaxPermSize are set to 80, which on the one hand avoids non heap warn (the alarm threshold is less than 60m for memory), and on the other hand avoids the pressure caused by heap expansion

◆ makes Eden area = from space=to space=8M by setting Xmn=24M and SurvivorRatio=1, which reduces the size of Eden area and the time of YGC (reduced to about 3-4ms). At the same time, by setting MaxTenuringThreshold=20, the growth of old gen is very slow. The problem is that the number of YGC has significantly increased.

For the benefits brought by the optimization and modification of other ◆ parameters, please see JVM parameter settings.

After improving again

-Xms128m-Xmx128m-Xmn36m-XX:PermSize=80m-XX:MaxPermSize=80m-Xss256k-XX:SurvivorRatio=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

Modify the point:

On the basis of the above, resize the Xmn to 36m and set the CMSInitiatingOccupancyFraction=73.

Both the Dden area and the Survivor area are increased to 12m. Through the CMSInitiatingOccupancyFraction calculation formula, it is calculated that the value is 73, which can avoid the promotion faild problem, and at the same time, the heap memory monitoring alarm value is 80%: memory size 128M*80%=102.4M 102.4M-36M=66.4M (the old generation reaches this value alarm) Full GC will occur when the old generation reaches 67.15m (92M*0.73). Therefore, when the size of the old generation reaches 66.4m, that is, when the WARN alarm is called, Full GC is very likely to occur.

Increasing the value of Eden and Survivor zone will reduce the number of YGC, but the increase of space will theoretically increase the time of YGC, but this change can be ignored because the new generation itself is very small (only 36m). The actual monitoring value shows that the time of YGC is between 4 and 5ms. It's an acceptable range.

The value of SurvivorRatio has to be carefully considered and needs to be optimized.

The configuration of some awesome person on the Internet: there is no problem with millions of pv every day, and the website does not stop.

$JAVA_ARGS. = "- Dresin.home=$SERVER_ROOT-server-Xms6000M-Xmx6000M-Xmn500M-XX:PermSize=500M-XX:MaxPermSize=500M-XX:SurvivorRatio=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"

Just to be clear,-XX:SurvivorRatio=65536-XX:MaxTenuringThreshold=0 means getting rid of the rescue space.

-Xnoclassgc disables class garbage collection, resulting in higher performance

-XX:+DisableExplicitGC forbids System.gc () to prevent programmers from mistakenly calling the gc method to affect performance

-XX:+UseParNewGC, which uses multi-thread parallel recycling for the younger generation, so it can be collected quickly.

Those with CMS parameters are related to concurrent recycling, and those who don't understand can be searched on the Internet.

CMSInitiatingOccupancyFraction, this parameter setting has great skill, basically satisfy (Xmx-Xmn) * (100-CMSInitiatingOccupancyFraction) / 100 > = Xmn will not appear promotion failed. In my application, Xmx is 6000 megabytes, so Xmx-Xmn is 5500 megabytes, that is, the old generation has 5500 megabytes. CMSInitiatingOccupancyFraction=90 said that when the older generation is 90% full next year, it will start to perform concurrent garbage collection (CMS) for the older generation. At this time, 10% of the space left is 5500 megabytes, so even if all the objects in the Xmn (that is, 500 megabytes of the younger generation) are moved to the older generation, 550 megabytes of space is enough. So as long as the above formula is satisfied, there will be no promotion failed during garbage collection.

I think the parameter SoftRefLRUPolicyMSPerMB may be 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's necessary to wait a second.

-Xmx4000M-Xms4000M-Xmn600M-XX:PermSize=500M-XX:MaxPermSize=500M-Xss256K-XX:+DisableExplicitGC-XX:SurvivorRatio=1-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:+CMSParallelRemarkEnabled-XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=0-XX:+CMSClassUnloadingEnabled-XX:LargePageSizeInBytes=128M-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 elderly generation is easy to be full, and the CMS implementation will be more frequent. I improved it a little bit. I still use the rescue space, but increase the rescue space so that there will be no promotion failed.

Specific operation, 32-bit Linux and 64-bit Linux seem to be different, 64-bit system seems to be configured as long as the MaxTenuringThreshold parameter, CMS is still paused. In order to solve the pause problem and promotion failed problem, * * I set-XX:SurvivorRatio=1 and remove the MaxTenuringThreshold, so that there is no pause and there will be no promotoin failed, and more importantly, the aging generation and the * * generation rise very slowly (because many objects are recycled before they reach the older generation), so the CMS execution frequency is very low, only once every several hours, so that the server does not have to restart.

A netizen:

$JAVA_ARGS. = "- Dresin.home=$SERVER_ROOT-server-Xmx3000M-Xms3000M-Xmn600M-XX:PermSize=500M-XX:MaxPermSize=500M-Xss256K-XX:+DisableExplicitGC-XX:SurvivorRatio=1-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:+CMSParallelRemarkEnabled-XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=0-XX:+CMSClassUnloadingEnabled-XX:LargePageSizeInBytes=128M-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 setting, the older generation grows very slowly, the frequency of CMS execution becomes smaller, CMS does not stagnate, there will be no promotion failed problems, and the memory is reclaimed cleanly.

After reading the above, do you have any further understanding of the examples and analysis of production environment parameters in JVM? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.