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

How to understand the JVM startup parameters, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Because the default values of parameters provided by Hotspot JDK are constantly changing from one version to another, the parameters will also affect each other. Moreover, different server configurations may affect the final effect. So don't blindly believe in the parameter configuration in an article on the website (including this one). All the configurations need to be tested by yourself.

If the default values of JVM parameters are constantly changing, you can use-XX:+PrintFlagsFinal to print the default values of current environment JVM parameters, such as java-XX:PrintFlagsFinal-version, or you can use java [production environment parameters]-XX:+PrintFlagsFinal-version | grep [parameters to be verified] to view specific parameter data.

Here are the parameters of an 8G server. The JDK version information is as follows:

Java version "1.8.073"

Java (TM) SE Runtime Environment (build 1.8.0_73-b02)

Java HotSpot (TM) 64-Bit Server VM (build 25.73-b02, mixed mode)

Heap settings

Heap memory setting should be regarded as the basic literacy of a Java programmer, at least Xms, Xmx, Xmn these three parameters have to be modified. But how much memory might a 2G heap JVM take up in total?

Heap memory + number of threads * thread stack + permanent generation + binary code + out-of-heap memory

2G + 1000 * 1m + 256m + 48max 240m + (~ 2G) = 5.5G (3.5g)

-Heap memory: stores Java objects. Default is 1x64 of physical memory.

-Thread stack: stores local variables (atomic types, references) and others. Default is 1m.

-permanent generation: storage class definition and constant pool, pay attention to the difference between JDK7/8

-binary code: JDK7 is different from 8 when opening multilayer compilation, ranging from 48 to 240m

-out-of-heap memory: used by Netty, out-of-heap cache, etc. The default maximum is about the size of heap memory

In other words, if the heap memory is set to 2G, a JVM with 1000 threads may need 5.5 GB. Considering the system usage, IO usage, and so on, an 8G server will start a service. Of course, if you have a small number of threads, low concurrency, and low pressure, you can still start multiple threads, and you can also reduce heap memory.

-Xms2g and-Xmx2g: heap memory size, the first is the minimum heap memory, the second is the maximum heap memory, the more appropriate value is 2-4g, no matter how large you have to consider the GC time

-Xmn1g or (- XX:NewSize=1g and-XX:MaxNewSize=1g) or-XX:NewRatio=1: set the Cenozoic size. JDK defaults to Cenozoic accounting for 1 of the heap memory size, that is,-XX:NewRatio=2. Here is the set 1g, that is,-XX:NewRatio=1. You can set it according to your own needs.

The eternal generation of-XX:MetaspaceSize=128m and-XX:MaxMetaspaceSize=512m,JDK8 can use up almost all the memory of the machine. In order to protect the server from being unable to connect because of excessive memory consumption, you need to set an initial value of 128m and a maximum value of 512m to protect it.

-XX:SurvivorRatio: the default size of each survival area in the new generation is 8, that is, 1 SurvivorRatio+2 10 of the new generation. Some people like to save points for the new generation, but to avoid being too small to hold temporary objects in the survival area and promote to the old generation, it is necessary to look at the actual situation from the GC Log.

-Xss256k: outside the heap, threads occupy stack memory, with a default of 1m per thread. Store the stack of the input parameter of the method call, the local variable, the local variable after scalar replacement, etc., some people like to set a small point to save memory and open more threads. However, it is not necessary to set a small amount of memory anyway, and some people like to set it bigger, especially when there are recursive calls such as JSON parsing.

-XX:MaxDirectMemorySize: the size of out-of-heap memory / direct memory, which defaults to heap memory minus the size of a Survivor area.

-the store area of XX:ReservedCodeCacheSize:JIT compiled binaries, which is no longer compiled when it is full. Multi-tier compiler 240m is turned on by default, and you can see the size of the CodeCache in JMX.

GC Settin

At present, the more mainstream GC is CMS and G1, and some great gods suggest 8G as the boundary. (it is said that JDK 9 defaults to G1.) Because the memory of the application settings is relatively small, choose the CMS collector. The following parameters are also for the CMS collector. Later, if necessary, supplement the parameters of the G1 collector.

CMS Settin

-XX:+UseConcMarkSweepGC: enable the CMS garbage collector

-XX:CMSInitiatingOccupancyFraction=80 and-XX:+UseCMSInitiatingOccupancyOnly: two parameters need to be used together, otherwise 75 of the first parameter is only a reference value, JVM will recalculate the time of GC.

-XX:MaxTenuringThreshold=15: how many times the object has survived the Young GC in Survival area and then promoted to the older generation. Default is 15. Young GC is the largest source of application pause, and the number of surviving objects after GC directly affects the pause time in the new generation, so if you know the execution frequency of Young GC and the longest life cycle of most temporary objects in the application, you can make it shorter, so that the new generation of long-term objects that are not temporary objects can be promoted to the old generation quickly.

-XX:-DisableExplicitGC: allows active invocation of GC using System.gc (). It needs to be explained here that some JVM optimization recommendations are to set-XX:-DisableExplicitGC and turn off the manual call System.gc (). This is because System.gc () triggers Full GC, and frequent Full GC can seriously affect performance. But many NIO frameworks, such as Netty, use out-of-heap memory, which cannot be reclaimed without Full GC. If you do not actively call System.gc (), you will have to wait until JVM itself triggers the Full GC, which may cause a long STW and increase the machine load. So instead of completely disabling System.gc () and shortening the Full GC time, use the-XX:+ExplicitGCInvokesConcurrent or-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses options and use the CMS collector to trigger the Full GC. These two options need to be used in conjunction with-XX:+UseConcMarkSweepGC.

-XX:+ExplicitGCInvokesConcurrent: triggers CMS GC instead of Full GC when System.gc () is used. It is not enabled by default, and can only be enabled if you use the-XX:+UseConcMarkSweepGC option.

-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses: when using System.gc (), the permanent generation is also included in the CMS scope. This option can be turned on only if you use the-XX:+UseConcMarkSweepGC option.

-XX:+ParallelRefProcEnabled: defaults to false, and parallel processing of Reference objects, such as WeakReference, will not have a significant effect unless there are logs with long Reference processing time in GC log.

-XX:+ScavengeBeforeFullGC: execute Young GC once before FullGC execution.

-XX:+UseGCOverheadLimit: limit the running time of GC. If GC takes too long, throw OOM.

-XX:+UseParallelGC: set parallel garbage collector

-XX:+UseParallelOldGC: set up parallel garbage collectors in the old days

-XX:-UseSerialGC: turn off the serial garbage collector

-XX:+CMSParallelInitialMarkEnabled and-XX:+CMSParallelRemarkEnabled: lower mark pause

-XX:+CMSScavengeBeforeRemark: defaults to off. Execute minor GC once before CMS remark to clear the new generation, so that the number of objects referenced from the old generation to the new generation is less, and the CMS remark phase of stopping the world is shorter. If you see the remark phase in the GC log for a long time, you can open this item to see if it has any effect, otherwise you'd better not open it. There are too many times of YGC in vain.

-XX:CMSWaitDuration=10000: sets the maximum time interval for garbage collection. The default is 2000.

-XX:+CMSClassUnloadingEnabled: cleans up expired Class in the permanent generation in CMS without waiting for Full GC,JDK7 to be turned off by default and JDK8 to open. It depends on your situation, such as whether you run dynamic language scripts such as Groovy to generate a large number of temporary classes. It increases the pause time for CMS remark, so it's better not to turn on this parameter if the new class is not loaded frequently.

GC log

The GC process can be optimized through GC logs.

-XX:+PrintGCDetails: enable gc log printing

-Xloggc:/path/to/gc.log: specify the gc log location

-XX:+PrintHeapAtGC: print detailed stack information before and after GC

-XX:+PrintGCDateStamps: prints a readable date instead of a timestamp

-XX:+PrintGCApplicationStoppedTime: print all the times that cause JVM pauses, and if you do find some pauses that you don't know, temporarily add-XX:+PrintSafepointStatistics-XX: PrintSafepointStatisticsCount=1 to find the cause.

-XX:+PrintGCApplicationConcurrentTime: print the normal running time of JVM between pauses, and it works better with-XX:+PrintGCApplicationStoppedTime.

-XX:+PrintTenuringDistribution: view the threshold of the new survival cycle after each minor GC

The-XX:+UseGCLogFileRotation and-XX:NumberOfGCLogFiles=10 and-XX:GCLogFileSize=10M:GC logs will be emptied after restart, but if an application is not restarted for a long time, the GC log will increase, so add these three parameters to make the GC log scroll to write to the file, but if you restart, the name may be confused.

-XX:PrintFLSStatistics=1: prints statistics of memory fragments before and after each GC

Other parameter settings

-ea: enable assertions, there is nothing to say about this, you can choose to enable it, or choose not to enable it, there is no big difference. Deal with it entirely according to your own system.

-XX:+UseThreadPriorities: enable thread priority mainly because we can give lower priority to periodic tasks to avoid interfering with client work. In my current environment, it is enabled by default.

-XX:ThreadPriorityPolicy=42: allows thread priority to be lowered

-XX:+HeapDumpOnOutOfMemoryError: heap-dump is used when memory overflow occurs.

-XX:HeapDumpPath=/path/to/java_pid.hprof: this parameter works with-XX:+HeapDumpOnOutOfMemoryError to set the content output file when heap-dump is set.

-XX:ErrorFile=/path/to/hs_err_pid.log: specifies the location of fatal error log. Usually, when a fatal error occurs in JVM, a file similar to hs_err_pid.log is output. By default, it is in the working directory (if you do not have permission, you will try to create it in / tmp). However, it is better to specify your own location, which is easy to collect and find to avoid loss.

-XX:StringTableSize=1000003: specifies the size of the string constant pool. The default value is 60013. Anyone with a little common sense of Java should know that strings are constants that cannot be modified after they are created. These constants are located in a place called string constant pools. If you have a lot of string operations in your system, and these string values are relatively fixed, you can appropriately increase the pool size if you allow it.

-XX:+AlwaysPreTouch: go through all the memory defined by all the parameters at startup. Using this parameter may slow startup, but it will be faster later in memory usage. The continuous allocation of memory pages can be ensured, and the GC pause will not be lengthened by applying for memory pages when the new generation is promoted. It usually feels only when the memory is greater than 32 gigabytes.

-XX:-UseBiasedLocking: disable biased locks (disabling biased locks can bring some performance optimization in an environment where there are a large number of lock objects created and highly concurrent (that is, non-multithreaded and highly concurrent applications).

-XX:AutoBoxCacheMax=20000: increase the scope of automatic boxing of digital objects. JDK defaults to the int and long of-128: 127. Objects will be created immediately if they are out of range, so increasing the scope can improve performance, but it also requires testing.

-XX:-OmitStackTraceInFastThrow: do not ignore the stack of repeating exceptions, which is the optimization of JDK. A large number of repeated JDK exceptions no longer print their StackTrace. However, if the system is a system that does not restart for a long time and runs N exceptions in the same place for many times, the result will be ignored by JDK, then you can't see the specific StackTrace when you check the log, and how to debug it, so it's better to turn it off.

-XX:+PerfDisableSharedMem: enables standard memory usage. JVM control is divided into standard or shared memory, the difference is that one is in JVM memory, the other is to generate / tmp/hsperfdata_ {userid} / {pid} files, store statistics, map to memory through mmap, and other processes can access content through files. With this parameter, you can prohibit JVM from writing statistics in the file, at the cost of not using commands such as jps and jstat, and can only obtain data through jmx. But in the troubleshooting is, jps, jstat these gadgets are very easy to use, much easier to use than heavy things like jmx, so you have to make your own choices. Here is an example of a GC pause.

-Djava.net.preferIPv4Stack=true: this parameter belongs to a network problem and can be set as needed. In some machines where ipv6 is turned on, the complete machine name can be obtained through InetAddress.getLocalHost (). GetHostName (), but in ipv4 machines, the machine name obtained by this method may be incomplete, and you can get the full machine name through this parameter.

The example given by the Great God

The example given by the Great God is posted below, which can be used for reference, but it is recommended to use it after the verification in your own environment. After all, the environment of the Great God is still different from your own environment.

Performance dependent

-XX:-UseBiasedLocking-XX:-UseCounterDecay-XX:AutoBoxCacheMax=20000

-XX:+PerfDisableSharedMem (optional)-XX:+AlwaysPreTouch-Djava.security.egd=file:/dev/./urandom

Memory size dependent (JDK7)

-Xms4096m-Xmx4096m-Xmn2048m-XX:MaxDirectMemorySize=4096m

-XX:PermSize=128m-XX:MaxPermSize=512m-XX:ReservedCodeCacheSize=240M

If you use jdk8, replace-XX:PermSize=128m-XX:MaxPermSize=512m with-XX:MetaspaceSize=128m-XX:MaxMetaspaceSize=512m. As mentioned earlier, these two sets of parameters are for security, and it is recommended to add them.

CMS GC correlation

-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=75

-XX:+UseCMSInitiatingOccupancyOnly-XX:MaxTenuringThreshold=6

-XX:+ExplicitGCInvokesConcurrent-XX:+ParallelRefProcEnabled

GC log related

-Xloggc:/dev/shm/app-gc.log-XX:+PrintGCApplicationStoppedTime

-XX:+PrintGCDateStamps-XX:+PrintGCDetails

Exception log correlation

-XX:-OmitStackTraceInFastThrow-XX:ErrorFile=$ {LOGDIR} / hs_err_%p.log

-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=$ {LOGDIR} /

JMX correlation

-Dcom.sun.management.jmxremote.port=$ {JMX_PORT}-Dcom.sun.management.jmxremote

-Djava.rmi.server.hostname=127.0.0.1-Dcom.sun.management.jmxremote.authenticate=false

-Dcom.sun.management.jmxremote.ssl=false

Reference article

Java performance Optimization Guide version 1.8, and VIPSHOP's actual combat

Escape Analysis and TLAB and Java object allocation in Java

The Four Month Bug: JVM statistics cause garbage collection pauses

=

Cassandra, the default JVM startup parameter on Linux systems

-ea

-Xms4096MB

-Xmx4096MB

-Xss128K

-XX:+UseThreadPriorities

-XX:ThreadPriorityPolicy=42

-XX:+HeapDumpOnOutOfMemoryError

-XX:+UseParNewGC

-XX:+UseConcMarkSweepGC

-XX:+CMSParallelRemarkEnabled

-XX:SurvivorRatio=8

-XX:MaxTenuringThreshold=1

-XX:CMSInitiatingOccupancyFraction=75

-XX:+UseCMSInitiatingOccupancyOnly

-ea starts with JDK1.4 and supports the assertion mechanism, which can be used to diagnose runtime problems. -ea is used to start the assertion mechanism of JVM. If packagename and classname are not added, assertions in all packages and classes are run by default. If you want to make assertions that run certain packages and classes, you can set it up like-ea:com.foo.util.

-XX:+UseThreadPriorities enables JAVA thread priority function

-profile of XX:ThreadPriorityPolicy JAVA thread priority

-XX:+HeapDumpOnOutOfMemoryError talks about data export in memory when a program crashes due to insufficient memory in JVM

-Xss128K sets the size of the thread stack. The default unit is bytes, or you can set it with KB or MB. Typically, the default size assigned by the operating system to the thread stack is 1MB. Alternatively, you can set the stack size when creating thread objects in JAVA CODE, Thread (TheadGroup group, Runnable target, String name, long stackSize)

-XX:+UseParNewGC reduces the time it takes JVM GC to perform minor collection

-XX:+UseConcMarkSweepGC reduces the time it takes JVM GC to perform major collection

-XX:+CMSParallelRemarkEnabled shortens the interrupt time for JVM GC to perform remark operations

-XX:SurvivorRatio sets the size ratio of young generation in survivor spaces

-XX:MaxTenuringThreshold indicates how many times an object has been moved in survivor spaces before it has been recycled before it is put into the old age

-XX:CMSInitiatingOccupancyFraction said that the old age accounted for about one percent of the time when the CMS operation was started.

The parameter-XX:+UseCMSInitiatingOccupancyOnly allows JVM to use only the values defined in CMSInitiatingOccupancyFraction without having to calculate them at run time

The answer to the question on how to understand the JVM startup parameters is shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to solve, you can follow the industry information channel for more related knowledge.

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.