This section only introduces the actual combat part. For specific theoretical parameters, please Baidu.
Required tools: linux server Jmeter test tool xshell a web application
Tomcat's JVM parameters can be configured in catalina.sh, and if it is on window, you can configure the .bat file.
Configuration 1:
Here I configured a gc log path as /home/log/gc.log to print the gc log, the initial heap and maximum heap memory is set to 50M, and when the output Dump file is overflowed, it uses a serial garbage collector, and the permanent generation size is 50m.
Put the web application in the corresponding directory, configure server.xml (the configuration is not introduced here), and start tomcat.
Throughput testing is performed using a pressure test tool (Jmeter). Students who have never used it can download and learn it on the official website http://jmeter.apache.org/
Create a user group (10 threads, each thread requests 1000 times), set up the information of the Http request, generate an aggregate report and a gc log
Let’s take a look at the gc log first:
Full GC on the screen, finally check the aggregate report:
Throughput is maintained at 122.7 per second. From this case we can see that the old generation is basically full, and after FUllGC, the new generation will have a little left. In general, the pause time of Full GC is the longest and happens so frequently, obviously such a configuration is unreasonable.
Configuration 2:
This configuration mainly increases the maximum heap memory. In order to automatically expand the virtual machine and obtain a stable heap memory size.
Just pay attention to the maximum heap memory of 82924k is about 80M, which means that the virtual machine automatically expands the heap memory to 80M and stabilizes it. This configuration test is just to find a stable heap memory for the next test.
Configuration Three:
Set the initial memory of the heap by 128m.
From the results of configuration 2, it can be seen that the heap memory is finally stable at around 80m, so a heap memory smaller than 80m is likely to cause a large number of GC reactions, so here I set the heap memory to 128M, which can reduce the number of GCs.
You can see that throughput has increased slightly, the number of GCs has decreased significantly, and the time intervals of GCs have become longer.
Configuration 4:
Currently using ParallalGC recycler, which is a multithreaded parallel recycler.
The throughput of GC recycler using multithreaded parallel has been slightly improved. (ParallalGC and serialGC have little effect on throughput without GC pressure.)
Configuration 5:
Configuration 6:
According to the conclusion of Configuration 3, GC will occur frequently in heap memory below 80M. Combined with the conclusion obtained in Configuration 4, when there is a certain GC pressure, the throughput of ParallelGC and serialGC will show certain differences. If the heap memory of 5 and 6 is configured with 64M<80M, frequent GC will occur. When using different GC recyclers, there will theoretically be a big difference in throughput, but why is the difference in my experiment not very big, and why? Hey, my family is poor. I use a single-core CPU. In the case of single-core, ParallelGC's performance changes are not obvious. SerialGC is recommended when single-core or parallel capabilities are weak. Students who have the conditions can try it with a multi-core server!
Configuration 7:
Try using ParNewGC. The new generation uses ParNewGC to recycle, while the old generation still uses SerialGC to recycle. See how the performance is?
It has better performance than using a serial recycler all, but worse performance than using a parallel recycler all.
In addition, the upgrade of the JDK version may also improve the performance a little, but the upgrade of the JDK version comes with certain risks, and some unknown bugs may be introduced into the new version of JDK.
Finally, I listed some commonly used JVM configuration parameters for reference:
1. Parameters related to the serial recovery period
•-XX:+UseSerialGC: Use serial collectors in the new and old generations
•-XX:SurvivorRatio: Set the size of the eden area and the ratio of the survivor area
•-XX:PretenureSizeThreshold: Set the threshold for large objects to directly enter the old age. When the size of the object exceeds this value, it will be allocated directly in the old age
•-XX:MaxTenuringThreshold: Sets the maximum age value of the object entering the old age. After each Minor GC, the age of the subject is added by 1. Any object greater than this age will definitely enter the old age.
2. Parallel GC-related parameters
•-XX:+UseParNewGC: Use parallel collectors in the new generation.
•-XX:+UseParallelOldGC: Use parallel collectors in the old age
•-XX:+ParallelGCThreads: Sets the number of threads used for garbage collection, which can usually be set to be equal to the number of CPUs. When there are a large number of CPUs, it is also possible to set a relatively small value.
•-XX:+MaxGCPauseMillis: Set the maximum garbage collection pause time. Its value is an integer greater than 0. When the collector works, it will adjust the size of the java heap or some other parameters, and control the pause time to MaxGCPauseMillis as much as possible.
•-XX: +UseAdaptiveSizePolicy: Turn on the adaptive GC strategy. In this mode, parameters such as the size of the new generation and the ratio of survivio, and the age of the object in the old generation will be automatically adjusted to achieve the balance point between heap size, throughput and pause.
•-XX:+GCTimeRatio: Set 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) of time on garbage collection.
3. Parameters related to CMS Collector
•-XX:+UseConcMarkSweepGC: The new generation uses parallel collectors, while the old generation uses CMS+serial collectors.
•-XX:ParallelCMSThreads: Set the number of threads for CMS.
•-XX:CMSInitiatingOccupancyFraction: Set how much CMS collector is triggered after the old age space is used, default 68%
•-XX:UseCMSCompactAtFullCollection: Set whether CMS needs to defragment once after completing garbage collection
•-XX:CMSFullGCBeforeCompaction: Set how many times CMS garbage collection is performed, and memory compression is performed.
•-XX:+CMSClassUnloadingEnabled: Allows the recovery of class metadata
•-XX:CMSInitiatingPermOccupancyFraction: When the permanent occupancy ratio reaches this percentage, start CMS recovery (provided that -XX:+CMSClassUnloadingEnabled is activated)
•-XX:UseCMSInitiatingOccupancyOnly: means that CMS recovery is only performed when the threshold is reached.
•-XX:+CMSIncrementalMode: Use incremental mode, which is more suitable for single CPU. Incremental mode is marked as discarded in the middle, and will be completely removed in jdk9.
4. Parameters related to G1 recovery period
•-XX:+UseG1GC: Use G1 Recovery
•-XX:+MaxGCPauseMillis: Set the maximum garbage collection pause time
•-XX:+GcPauseIntervalMillis: Set the pause time interval.
5. TLAB related
•-XX:+UseTLAB: Turn on TLAB allocation.
•-XX:+PrintTLAB: Print TLAB related allocation information
•-XX:TLABSize: Set TLAB size
•-XX:+ResizeTLAB: Automatically adjust the TLAB size
6. Some other parameters
•-XX:+DisableExplicitGC: Disable explicit GC
•-XX:+ExplicitGCInvokesConcurrent: Use concurrency to handle explicit GC
The above JVM Tomcat performance practical (recommended) is all the content I share with you. I hope you can give you a reference and I hope you can support Wulin.com more.