JVM Tomcat Performance Combat

This section is only to introduce the actual combat part, the specific theoretical parameters, please own Baidu.

Tools Required: Linux Server JMeter Test tool Xshell a Web application

The JVM parameters of Tomcat can be configured on the catalina.sh, if the. bat file can be configured on the window

Configuration 1:

Here I configured a GC log path for/home/log/gc.log, print GC log, initial heap and Max heap memory set to 50M, output dump file in memory overflow, use serial garbage collector, permanent generation size is 50m.

Put the Web application in the corresponding directory, configure the Server.xml (no configuration is described here), SH start.sh start Tomcat.

Test the throughput using the pressure measuring tool (Jmeter). No use of students can be the officer of the Web download study http://jmeter.apache.org/

Establish user groups (10 threads, 1000 requests per thread), set up HTTP request information, generate an aggregated report and a GC log

Let's take a look at the GC log:

Full GC on screen, last view aggregation report:

Throughput is maintained at 122.7 per second. From this case we can see that the old age 34176k is almost full, after FULLGC, the new generation will have a little space left. Overall, the full GC's pause time is the longest, and it happens so often that this configuration is unreasonable.

Configuration 2:

This configuration is mainly to increase the maximum heap memory. In order to automatically expand the virtual machine, to obtain a stable heap memory size.

Just pay attention to a bit of the maximum heap memory is about 82924k 80M, that is, the virtual machine to the heap memory automatically expanded to 80M, and stabilized. This configuration test is just to find a stable heap of memory for the next test.

Configuration three:

Sets the initial memory of the heap to 128m.

The result of configuration 2 shows that the heap memory is finally stable around 80m, so less than 80m of heap memory, it is likely to cause a lot of GC reaction, so here I set the heap memory to 128M, can reduce the number of GC.

You can see a slight increase in throughput, a significant decrease in GC times, and a longer time interval for GC.

Configuration four:

Currently using the PARALLALGC collector, this is a multithreaded parallel collector.

There is a slight increase in the throughput of the GC collector using multithreaded parallelism. (In the absence of GC pressure, PARALLALGC and SERIALGC have little impact on throughput.) ）

Configuration five:

Configuration Six:

According to the conclusion of configuration three, the heap memory under 80M will occur frequently GC, and then combined with the results obtained in configuration four the throughput of PARALLELGC and SERIALGC will show a certain difference when there is a certain GC pressure.   Configuration five and configuration six of the heap memory 64m<80m, will occur frequently GC, the use of different GC collector, in theory, there will be a greater difference in throughput, but my experiment why the gap is not very large, in the end why? Eh, home is poor, I use a single core CPU, in the case of single core PARALLELGC change performance is not obvious. It is recommended to use SERIALGC in the case of a single core or weak parallel capability. Qualified students can use a multi-core server to try Oh!

Configuration Seven:

Use PARNEWGC to try, the new generation uses PARNEWGC recovery, the old age still uses SERIALGC recycling. See how it performs?

The performance is better than using the serial collector in all, but the performance is worse than using the full parallel collector.

In addition, the JDK version upgrade may also make a bit of performance improvements, but JDK version upgrade with a certain risk, perhaps in the new version of the JDK introduced some unknown bugs.

Finally, I list some common JVM configuration parameters for reference:

1. Parameters related to serial payback period

-XX:+USESERIALGC: Using a serial collector in the new generation and the old age

-xx:survivorratio: Set the size of the Eden area and the scale of the survivor area

-xx:pretenuresizethreshold: Sets the threshold for large objects to enter the old age directly. When the size of the object exceeds this value, it will be allocated directly in the old age

-xx:maxtenuringthreshold: Sets the maximum age for an object to enter the old years. Each time the GC is minor, the age of the object is added 1. Any object greater than this age is bound to enter the old age.

2. Parameters related to parallel GC

-XX:+USEPARNEWGC: Using a parallel collector in the Cenozoic.

-XX:+USEPARALLELOLDGC: Using parallel collectors in the old age

-xx:+parallelgcthreads: Sets the number of threads used for garbage collection, which can usually be set to equal to the number of CPUs. With a large number of CPUs, setting a relatively small value is also possible.

-xx:+maxgcpausemillis: Sets the maximum garbage collection pause time. Its value is an integer greater than 0. When the collector is working, it adjusts the size of the Java heap or some other parameters, as much as possible to control the pause time within Maxgcpausemillis.

-xx:+useadaptivesizepolicy: Turn on adaptive GC policy, in this mode, the size of the Cenozoic and the proportion of Survivior, the age of the promotion of older age and other parameters will be automatically adjusted to reach the balance between heap size, throughput and pause.

-xx:+gctimeratio: Sets the throughput size. Its value is a certificate between 0 and 100. Assuming that the value of Gctimeratio is N, the system will spend no more than 1/(1+n) for garbage collection.

3. Parameters related to the CMS collector

-XX:+USECONCMARKSWEEPGC: The new generation uses the parallel collector, the older generation uses the cms+ serial collector.

-xx:parallelcmsthreads: Sets the number of threads for the CMS.

-xx:cmsinitiatingoccupancyfraction: Set the CMS collector to trigger after the old age space is used, default 68%

-xx:usecmscompactatfullcollection: Set whether the CMS will defragment once after the garbage collection is complete

-xx:cmsfullgcbeforecompaction: Sets the number of times the CMS garbage collection is performed, and then the memory is compressed once.

-xx:+cmsclassunloadingenabled: Allow recycling of class metadata

-xx:cmsinitiatingpermoccupancyfraction: When the permanent generation share reaches this percentage, start the CMS recycle (provided the-xx:+cmsclassunloadingenabled is activated)

-xx:usecmsinitiatingoccupancyonly: Indicates that the CMS is only recycled when the threshold is reached.

-xx:+cmsincrementalmode: Use incremental mode, which is more suitable for single CPU. Incremental mode is marked obsolete in, JDK9 will be removed completely

4. Parameters related to the G1 payback period

-XX:+USEG1GC: Using the G1 collector

-xx:+maxgcpausemillis: Setting the maximum garbage collection pause time

-xx:+gcpauseintervalmillis: Sets the pause interval.

5.TLAB related

-xx:+usetlab: Turn on Tlab assignment.

-xx:+printtlab: Print Tlab related distribution information

-xx:tlabsize: Set Tlab size

-xx:+resizetlab: Auto tlab size adjustment

6. Some other parameters

-XX:+DISABLEEXPLICITGC: Disabling an explicit GC

-xx:+explicitgcinvokesconcurrent: Handling explicit GC using concurrency

JVM Tomcat Performance Combat