I changed the parameters, and it doubled the performance of Tomcat and JVM!

Preface

At work, as a Java developer, Tomcat server is commonly used by everyone, and it is also used by many companies now. However, when the concurrency of the system is relatively large, Tomcat will be stuck and automatically shut down. How to optimize Tomcat and make it run more efficiently has become a problem. In this editor, I will share with you how to better improve Tomcat performance.

Tomcat performance tuning

Find the conf directory under the Tomcat root directory and modify the content of the server.xml file. The editor here has also compiled a copy of more than 400 pages of study notes on JVM tuning and actual combat. Pay attention to the official account: Kylin's bug fix and get detailed PDF. For the tuning of this part, what I know is nothing more than setting up the Tomcat server. The settings of the maximum concurrency and the number of threads created when Tomcat is initialized, and of course there are other performance tuning settings. The following figure shows some parameter values ​​I set based on the performance of my machine. Let me explain in detail to you:

I changed the parameters, and it doubled the performance of Tomcat and JVM!

1. URIEncoding="UTF-8": Set the character set of Tomcat. We generally don't set this configuration, because we will deal with the conversion of garbled characters in specific projects. It is too rigid to modify the character set of Tomcat directly.

2. maxThreads="300": Set the maximum concurrent number of Tomcat. The maximum number of requests configured by Tomcat by default is 150, which means that it can support 150 concurrent requests. However, in practical applications, the maximum number of concurrency has a lot to do with hardware performance and the number of CPUs. Better hardware and higher processors will enable Tomcat to support more concurrency. If generally in actual development, when an application has more than 250 concurrency, the application server cluster will be considered.

3. minSpareThreads="50": Set the number of threads created when the current Tomcat is initialized. The default value is 25.

4. AcceptCount="250": When the number of simultaneous connections reaches the value set by the maxThreads parameter, it can also receive the number of queued connections, and if it exceeds this connection, it will directly return to reject the connection. Specify the number of requests that can be placed in the processing queue when any number of threads that can be used to process requests are used. Requests exceeding this number will not be processed. The default value is 100. In practical applications, if you want to increase the number of concurrent Tomcat, you should increase the acceptCount and maxThreads values. Reorganization: WeChat public account, Soyunku technical team, ID: souyunku

5. enableLookups="false": Whether to enable domain name back-checking, it is generally set to false to improve processing capacity. Its value is also true, which is generally rarely used.

6. maxKeepAliveRequests="1": nginx is dynamically transferred to tomcat, nginx cannot keepalive, and tomcat has keepalive enabled by default and will wait for the keepalive timeout. The default setting is to use connectionTimeout. So you must set the tomcat timeout time and turn off the tomcat keepalive. Otherwise, a lot of tomcat socket timewait will be generated.

maxKeepAliveRequests=”1” can prevent tomcat from generating a large number of TIME_WAIT connections, thereby avoiding tomcat suspended animation to a certain extent.

JVM performance tuning

Tomcat itself is still running on the JVM, we can make Tomcat have better performance by adjusting the JVM parameters. Currently there are two main aspects of tuning for JVM: memory tuning and garbage collection strategy tuning.

One, memory tuning

Find the bin directory under the Tomcat root directory and set the JAVA_OPTS variable in the catalina.sh file, because the subsequent startup parameters will treat JAVA_OPTS as the startup parameters of the JVM. Besides, the memory structure of the Java virtual machine is a bit complicated. I believe that many people are very abstract in understanding. It is mainly divided into several parts such as heap, stack, method area and garbage collection system. The following is what I picked from the Internet The memory structure diagram:

I changed the parameters, and it doubled the performance of Tomcat and JVM!

The memory tuning is nothing more than modifying the size of their respective memory space to make the application more reasonable. The following figure shows the parameters I set according to the performance of my machine. Let me explain the meaning of each parameter in detail. :

I changed the parameters, and it doubled the performance of Tomcat and JVM!

1. -Xmx512m: Set the maximum available memory size of the heap of the Java virtual machine, unit: mega (m), the entire heap size = young generation size + old generation size + persistent generation size. The permanent generation generally has a fixed size of 64m. The different distribution of the heap will have a certain impact on the system. Keep objects in the young generation as much as possible, and reduce the number of GCs in the old generation (usually the old age collection is slower).

In actual work, the initial value and maximum value of the heap are usually set equal, which can reduce the number of garbage collections and space expansion during program operation, thereby improving program performance. Reorganization: WeChat public account, Soyunku technical team, ID: souyunku

2. -Xms512m: Set the initial memory size of the heap of the Java virtual machine, unit: mega (m), this value can be set the same as -Xmx to avoid the JVM reallocating memory after each garbage collection is completed.

3. -Xmn170m: Set the memory size of the young generation, in megabytes (m). This value has a greater impact on system performance. Sun officially recommends a configuration of 3/8 of the entire heap. Generally, after increasing the memory of the young generation, the size of the old generation will also be reduced.

4. -Xss128k: Set the stack size of each thread. After JDK5.0, the size of each thread stack is 1M, and the size of each thread stack is 256K before. Adjust the memory size required by the application thread.

Under the same physical memory, reducing this value can generate more threads. However, the operating system still has a limit on the number of threads in a process, which cannot be generated indefinitely. The experience value is around 3000~5000.

5. -XX:NewRatio=4: Set the ratio of the young generation (including Eden and two Survivor areas) to the old generation (excluding the permanent generation). Set to 4, the ratio of the young generation to the old generation is 1:4, and the young generation accounts for 1/5 of the entire stack.

6. -XX:SurvivorRatio=4: Set the size ratio of the Eden area to the Survivor area in the young generation. Set to 4, the ratio of two Survivor areas to one Eden area is 2:4, and one Survivor area occupies 1/6 of the entire young generation.

7. -XX:MaxPermSize=16m: Set the persistent generation size to 16m. As mentioned above, the permanent generation generally has a fixed memory size of 64m.

8. -XX:MaxTenuringThreshold=0: Set the maximum age of garbage.

If it is set to 0, the young generation object does not pass through the Survivor area and directly enters the old generation. For applications with more old generations, efficiency can be improved.

If this value is set to a larger value, the young generation object will be copied multiple times in the Survivor area, which can increase the survival time of the object in the young generation and increase the general theory of being recycled in the young generation.

Two, garbage collection strategy tuning

Find the bin directory under the Tomcat root directory and set the JAVA_OPTS variable in the catalina.sh file. We all know that the Java virtual machine has a default garbage collection mechanism, but the efficiency of different garbage collection mechanisms is different. It is precisely because of this that we often adjust the garbage collection strategy of the Java virtual machine accordingly. The following is also a garbage collection strategy configured through some of my requirements:

I changed the parameters, and it doubled the performance of Tomcat and JVM!

The garbage collection strategy of the Java virtual machine is generally divided into: serial collector, parallel collector and concurrent collector.

Serial collector:

1. -XX:+UseSerialGC: represents that the garbage collection strategy is a serial collector, that is, the entire scanning and copying process is performed in a single-threaded manner, which is suitable for single CPU, small space of the new generation and not very demanding pause time For high-level applications, it is the default GC method at the client level, mainly the garbage collection method before JDK1.5.

Concurrent collector:

1. -XX:+UseParallelGC: Represents the garbage collection strategy as the parallel collector (throughput priority), that is, the entire scanning and copying process is performed in a multi-threaded manner, suitable for applications with multiple CPUs and short pause time requirements The above is the default GC method used at the server level. This configuration is only valid for the young generation. This configuration only allows the young generation to use concurrent collection, while the old generation still uses serial collection. Reorganization: WeChat public account, Soyunku technical team, ID: souyunku

2. -XX:ParallelGCThreads=4: Configure the number of threads of the parallel collector, that is, how many threads are garbage collected together at the same time. This value is best configured to be equal to the number of processors.

3. -XX:+UseParallelOldGC: Configure the old generation garbage collection method as parallel collection. JDK6.0 supports parallel collection of the old generation.

4. -XX:MaxGCPauseMillis=100: Set the maximum time for each young generation garbage collection. If this time cannot be met, the JVM will automatically adjust the size of the young generation to meet this value.

5. -XX:+UseAdaptiveSizePolicy: After setting this option, the parallel collector will automatically select the young generation area size and the corresponding Survivor area ratio to achieve the minimum corresponding time or collection frequency specified by the target system. This value is recommended to use parallel collection The device is always on.

Concurrent collector:

1. -XX:+UseConcMarkSweepGC: Represents the garbage collection strategy as a concurrent collector.

to sum up

Well, so far I have summarized the garbage collection strategy of the virtual machine. The editor here also compiled a copy of more than 400 pages of study notes on JVM tuning and actual combat. Pay attention to the official account: Kylin’s bug, get the detailed PDF, This is the same sentence: Optimal learning has been on the way. Below is an excerpt from other blogs. It is said that the above three GC mechanisms need to be used in conjunction.

I changed the parameters, and it doubled the performance of Tomcat and JVM!

Guess you like

Origin blog.51cto.com/14994509/2592720