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 |
| -XX:MetaspaceSize |
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 |
| -XX：+UseParallelGC | 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 |
| -XX：+PrintGCApplicationStoppedTime |
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的时间戳 |
2、tomcat配置调优，调整tomcat/conf/server.xml中关于链接器的配置可以提升应用服务器的性能
| 参数 | 说明 |
| maxConnections | 最大连接数，当达到该值后，服务器接收单不会处理更多的请求，额外的请求将会阻塞直到连接数低于maxConnections。可通过ulimit -a查看服务器限制。对于CPU要求更高（计算型）时，建议不要配置过大；对于cpu要求不是特别高时，建议配置在2000左右。当然这个需求服务器硬件的支持 |
| maxThreads | 最大线程数，需要根据服务器的硬件情况，进行一个合理的设置 |
| acceptCount | 最大排队等待数，当服务器接收的请求数量到大maxConnections，此时Tomcat会将后面的请求，存放在任务队列中进行排序，acceptCount指的就是任务队列中排队等待的请求数。一台Tomcat的最大请求处理数量，是maxConnections+acceptCount |