cool hit counter Example of setting JVM tuning parameters in a production environment_Intefrankly

Example of setting JVM tuning parameters in a production environment


JVM Basics: Production Environment Parameters Example and Analysis

Original configuration.

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

Question.

◆ permsize Smaller settings, It's easy to reach alarm range(0.8)

◆ No MaxPermSize is set, and heap growth can cause additional stress.

◆ NewSize is larger, old gen remaining space 64m, on the one hand, it may bring the old area easy to grow to the alarm range (monitoring data shows oldgenused for a long time around 50m, close to 78%, easy to have full gc), on the other hand, there is also the risk of prolontion fail.

Jvm memory tuning.

-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 

Modification points.

◆ PermSize and MaxPermSize are both set to 80 to avoid non heap warn (alarm threshold 0.8) and to avoid the pressure from heap scaling.

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

◆ Other parameter optimization The benefits of the modification are described in detail in another article on parameters

Again with memory tuning.

-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 

Modification points.

Adjust the Xmn size to 36M on top of the above and set CMSInitiatingOccupancyFraction=73.

Both the Dden and Survivor zones are increased in size to 12M by CMSInitiatingOccupancyFraction calculation formula, calculatevalue because of73 be, Can be avoidedpromotion faild issues, owing to The size of the yearly old age is (128m - 36m)0*(1-0.73) = 24.86m It's perfectly fine to put oneEden Size of the zone;

Also meet the heap memory monitoring alarm value at80%: Memory size128M*80%=102.4M, 102.4M-36M=66.4M ( Older generations will also be alerted when this value is reached Older generations reach92M*0.73 =67.15M) put in placeFull GC, So in the older generations size reaches66.4M That is, whenWARN The alarm will most likely be called whenFull GC。

Increasing the values of the Eden and Survivor zones will reduce the number of YGCs, but the larger space will theoretically increase the YGC time accordingly, but since the new generation itself is small (only 36M) this change can be ignored. The actual monitored values show YGC times between 4-5ms. is within acceptable limits.

SurvivorRatio is a value that needs to be carefully considered, and is still being optimized.

Some bull on the internet has a configuration :millions of pv per day with no problems at all, no site downtime

$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  
"; 

In this tuning setup.

-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0 The purpose is to remove the salvage space That is, of the younger generation onlyEden distinguish Eden object of It'll go straight to the year-old district.;

-Xnoclassgc Disable class garbage collection, performance will be a little higher.

-XX:+DisableExplicitGC to disable System.gc(), lest programmers accidentally call the gc method and affect performance.

-XX:+UseParNewGC, which uses multi-threaded parallel recovery for younger generations so that they are collected quickly.

with CMS (Concurrent Collection Algorithm) parameters are related to concurrent recovery and can be searched online if not understood.

CMSInitiatingOccupancyFraction, a parameter that is set with great skill, basically satisfies the following equation.

(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn

there would be no promotion failure.

In my application Xmx is 6000 and Xmn is 500, so Xmx-Xmn is 5500 megabytes, that is, the old generation has 5500 megabytes, CMSInitiatingOccupancyFraction=90 means that the old generation starts to perform concurrent garbage collection (CMS) on the old generation when it is 90% full, at this time there is 10% space left is 5500*10%=550 megabytes, so even if all objects in Xmn (that is, the young generation has a total of 500 megabytes) are moved to the old generation, 550 megabytes of space is enough, so as long as the above formula is satisfied, there will be no promotion failure in garbage collection.

SoftRefLRUPolicyMSPerMB This parameter I think might be somewhat useful, the official explanation is that 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 see the need to wait 1 second.

Continuing with jvm tuning.

-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 

Description of improvements:

The first tuning method is not very good, because the salvage space is not used, so the older generations tend to be full, and the CMS will be executed more frequently (one GC for the older generations, then one GC for the younger generations, which is equivalent to a Full GC). I improved it a bit, still using bailout space, but increasing the bailout space so it doesn't have promotion failed either. Specifically, it seems that 32-bit Linux and 64-bit Linux are different, and it seems that 64-bit systems still have CMS pauses as long as the MaxTenuringThreshold parameter is configured. In order to solve the pause problem and promotion failed problem, finally I set -XX:SurvivorRatio=1 and remove MaxTenuringThreshold, so that there is no pause and no promotion failed, and more importantly, the ageing generation and permanent generation rise very slowly (because many objects are recycled before reaching the ageing generation), so the CMS execution frequency is very low, only once in several hours, so that the server does not even need to restart.

Tuning scheme of a webmaster.

$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 setup, older generations go up very slowly, CMS execution becomes less frequent, CMS does not stall and there are no promotion failed issues, memory is reclaimed cleanly.


Recommended>>
1、IndustryNew research from FeiFei Lis team visual AI gives hospital germs nowhere to go
2、How to experience Laravel 55 in advance
3、AndroidStudio 22 JNI compilation and Rxjava use primer background
4、P3372 Template Line Tree 1 interval query and interval modification
5、kubernetes learning record 8 Chinese interface version of dashboard installation

    已推荐到看一看 和朋友分享想法
    最多200字,当前共 发送

    已发送

    朋友将在看一看看到

    确定
    分享你的想法...
    取消

    分享想法到看一看

    确定
    最多200字,当前共

    发送中

    网络异常,请稍后重试

    微信扫一扫
    关注该公众号