JVM Tomcat performance Combat (recommended) _java

This section only introduces the actual combat part, the concrete theory parameter, please own Baidu.

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

Tomcat JVM parameters can be configured in catalina.sh, if the. bat file can be configured on Windows

Configuration 1:

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

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

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

Set up user groups (10 threads, 1000 requests per thread), set up information for HTTP requests, generate an aggregation report and a GC log

Let's take a look at GC logs first:

Full GC, last view aggregation report:

Throughput is maintained at 122.7 per second. From this case we can see the old age 34176k is basically full, after FULLGC after the Cenozoic will have a little space left. In general, the full GC pause time is the longest and occurs so frequently that this configuration is obviously unreasonable.

Configuration 2:

This configuration is mainly to increase the maximum heap memory. So that the virtual machine can be automatically expanded to obtain a stable heap memory size.

Just focus on the maximum heap memory of 82924k 80M or so, which means that the virtual machine automatically expands the heap memory to 80M and stabilizes. This configuration test is just to find a stable heap memory so that the next test.

Configuration three:

Sets the initial memory 128m of the heap.

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

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 GC collector using multithreading 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 GC is frequent in heap memory under 80M, and the PARALLELGC and SERIALGC throughput 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 frequent GC, the use of different GC collector, the theory will be in the throughput of a large difference, but my experiment why the gap is not very big, in the end why? Eh, the family 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 weak single core or parallel capability. Conditional students can use multi-core server to try Oh!

Configuration Seven:

Try with PARNEWGC, Cenozoic use PARNEWGC recycling, old age still use SERIALGC recycling. See how the performance is?

Performance is better than using the serial collector in its entirety, but the performance is worse than using the parallel collector in its entirety.

Additional JDK upgrades may also make performance a bit higher, but there is a risk that JDK version upgrades may introduce some unknown bugs in a new version of the JDK.

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

1. Parameters associated with the serial recovery period

-XX:+USESERIALGC: Using serial collectors in the Cenozoic and old age

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

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

-xx:maxtenuringthreshold: Sets the maximum age for an object to enter the old era. After each minor GC, the object age is 1. Any object greater than this age is bound to enter the old age.

2. Parameters related to parallel GC

-XX:+USEPARNEWGC: Parallel collectors are used in the Cenozoic.

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

-xx:+parallelgcthreads: Sets the number of threads to use for garbage collection, which can usually be set to equal the number of CPUs. The number of CPUs in the case, set a relatively small number can also be.

-xx:+maxgcpausemillis: Set 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 to control the pause time within Maxgcpausemillis as much as possible.

-xx:+useadaptivesizepolicy: Open Adaptive GC strategy, in this mode, the new generation size and survivior ratio, promotion of old age of the object ages and other parameters will be automatically adjusted to reach the heap size, throughput and pause between the balance point.

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

3. Parameters related to the CMS collector

-XX:+USECONCMARKSWEEPGC: The new generation uses parallel collectors, the old age uses cms+ serial collectors.

-xx:parallelcmsthreads: Number of threads to set up CMS.

-xx:cmsinitiatingoccupancyfraction: Set up the CMS collector in the old age space is used after the number of triggers, default 68%

-xx:usecmscompactatfullcollection: Set up CMS to defragment once the garbage collection is complete

-xx:cmsfullgcbeforecompaction: Set the number of CMS garbage collection after a memory compression.

-xx:+cmsclassunloadingenabled: Allow collection of class meta data

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

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

-xx:+cmsincrementalmode: Using incremental mode, it is more suitable for single CPU. Incremental mode is marked as obsolete in, Jdk9 is completely removed

4. Parameters related to the G1 recovery period

-XX:+USEG1GC: Using the G1 collector

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

-xx:+gcpauseintervalmillis: Sets the pause interval.

5. Tlab Related

-xx:+usetlab: Open Tlab distribution.

-xx:+printtlab: Print Tlab related distribution information

-xx:tlabsize: Set Tlab size

-xx:+resizetlab: Automatically resize Tlab

6. Some other parameters

-XX:+DISABLEEXPLICITGC: Disabling an explicit GC

-xx:+explicitgcinvokesconcurrent: Handling explicit GC with concurrent methods

The above JVM Tomcat performance Combat (recommended) is a small series to share all the content, I hope to give you a reference, but also hope that we support the cloud-dwelling community.