tomcat optimization configuration items

Jvm memory configuration optimization, GC garbage collection optimization

1. Jvm memory parameter adjustment to improve tomcat performance

parameter Parameter function Optimization suggestion
-server Start Server and run in server mode Server mode is recommended to be turned on
-Xms Minimum heap memory It is recommended to set the same as -Xmx
-Xmx Maximum heap memory It is recommended to set the same as -Xmx


Initial value of metaspace  
-XX:MaxMetaspaceSize Maximum memory in meta space Unlimited by default
-XX:MaxNewSize New generation maximum memory

Default 16M

-XX:NewRatio The ratio of the young generation to the old generation, the value is an integer, and the default is 2. Not recommended to modify
-XX:SurvivorRatio The ratio of the size of the Eden area to the Survivor area, the value is an integer, and the default is 8 Not recommended to modify










2. GC strategy

The main indicators of jvm garbage collection performance:

Throughput: working time (excluding gc time) as a percentage of the total time. Working time is not only the time the program runs, but also the memory allocation time

Pause time: The number of times/time that the application stops responding due to garbage collection during the test period.

 Garbage collector type

Garbage collector Meaning description
Serial Collector (Serial Collector) It uses a single thread to perform all garbage collection work, which is suitable for single-core CPU servers and cannot take advantage of the advantages of multi-core hardware.
Parallel Collector (Parallel Collector) Also known as the throughput collector, it performs the garbage collection of the young generation in a parallel manner, which can significantly reduce the overhead of garbage collection (referring to multiple garbage collection threads working in parallel, but at this time the user thread is still in a waiting state). Suitable for applications with a large amount of data running on multi-processor or multi-threaded hardware
Concurrent Collector (Concurrent Collector) Perform most of the garbage collection in a concurrent manner to shorten the pause time of garbage collection. It is suitable for applications where response time is prior to throughput, because although the collector minimizes the pause time (refers to the user thread and the garbage collection thread are executed at the same time, but not necessarily in parallel, may alternate), but it will reduce the application The performance of the program
CMS Collector (Concurrent Mark Sweep Collector) Concurrent mark-and-sweep collector, suitable for applications that are more willing to shorten the pause time of garbage collection and can afford to share processor resources with garbage collection
G1 Collector (Garbage-First Garbage Collector) Multi-core servers suitable for large-capacity memory can achieve high throughput with the greatest possible possibility while meeting the garbage collection pause time goal (after JDK1.7)








GC parameter configuration

parameter description
-XX:+UseSerialGC Enable serial collector

Enable the parallel garbage collector, configure this option, then -XX: -UseParallelOldGC

-XX:+UseParallelOldGC FullGC, using parallel collection, disabled by default, if -XX:+UseParallelGC is set, it will start automatically
-XX:+UseParNewGC The young generation uses a parallel collector. If set, the -XX:+UseConcMarkSweepGC option will start automatically
-XX:ParallelGCThreads The number of threads used by garbage collection in the young and old generations. The default value depends on the number of CPUs used by the JVM
-XX:+UseConcMarkSweepGC For the old age, start the CMS garbage collector. When the parallel collector cannot meet the delay requirements of the application, it is recommended to use the CMS or G1 collector. After this option is enabled, -XX:+UseParNewGC is automatically enabled
--XX:+UseG1GC Enable the G1 collector. G1 is a server-type collector for machines with multiple cores and large memory. It has a high probability of meeting the goal of GC pause time while maintaining high throughput











We can print out the gc information after adjusting the jvm parameters during the test, so as to provide a basis for us to adjust the parameters. The specific parameters are as follows:

Options description
-XX:+PrintGC Print the information of each GC
-XX:+PrintGCApplicationConcurrentTime Print the elapsed time after the last pause, that is, the time to respond to concurrent execution


Application pause time when printing GC
-XX:+PrintGCDateStamps Print the date stamp of each GC
-XX:PrintGCDetails Print the detailed information of each GC
-XX:+PrintGCTaskTimeStamps Print the timestamp of each GC worker thread task
-XX:+PrintGCTimesStamps 打印每次GC的时间戳



参数 说明
maxConnections 最大连接数,当达到该值后,服务器接收单不会处理更多的请求,额外的请求将会阻塞直到连接数低于maxConnections。可通过ulimit -a查看服务器限制。对于CPU要求更高(计算型)时,建议不要配置过大;对于cpu要求不是特别高时,建议配置在2000左右。当然这个需求服务器硬件的支持
maxThreads 最大线程数,需要根据服务器的硬件情况,进行一个合理的设置
acceptCount 最大排队等待数,当服务器接收的请求数量到大maxConnections,此时Tomcat会将后面的请求,存放在任务队列中进行排序,acceptCount指的就是任务队列中排队等待的请求数。一台Tomcat的最大请求处理数量,是maxConnections+acceptCount


Guess you like