Java virtual machine tuning (eight)-typical configuration examples 2

Background :

I’ve always wanted to share the things about the java virtual machine. I have been working on it for a long time. It’s too theoretical, and I can’t write too many special things. I see that some friends have shared it very well, and it has been organized into a system, so I will reprint it. , I hope it is useful to friends, welcome to pay attention to Pharaoh's official account [Software Pharaoh], and pay attention to not getting lost.


Summary of common configurations

Heap settings

-Xms : initial heap size

-Xmx : Maximum heap size

-XX:NewSize=n : Set the young generation size

-XX:NewRatio=n : Set the ratio between the young generation and the old generation. For example: 3, which means that the ratio of the young generation to the old generation is 1:3, and the young generation accounts for 1/4 of the total of the young generation and the old generation.

-XX:SurvivorRatio=n : The ratio of the Eden area to the two Survivor areas in the young generation. Note that there are two Survivor areas. For example: 3 means Eden: Survivor=3: 2, a Survivor area occupies 1/5 of the entire young generation

-XX:MaxPermSize=n : set the persistent generation size

Collector settings

-XX:+UseSerialGC : Set the serial collector

-XX:+UseParallelGC : Set the parallel collector

-XX:+UseParalledlOldGC : Set the parallel old generation collector

-XX:+UseConcMarkSweepGC : Set the concurrent collector

Garbage collection statistics

-XX:+PrintGC

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-Xloggc:filename

Parallel collector settings

-XX:ParallelGCThreads=n : Set the number of CPUs used by the parallel collector for collection. The number of parallel collection threads.

-XX:MaxGCPauseMillis=n : Set the maximum pause time for parallel collection

-XX:GCTimeRatio=n : Set garbage collection time as a percentage of program running time. The formula is 1/(1+n)

Concurrent collector settings

-XX:+CMSIncrementalMode : set to incremental mode. It is suitable for single CPU.

-XX:ParallelGCThreads=n : Set the number of CPUs used when the young generation collection mode of the concurrent collector is parallel collection. The number of parallel collection threads.

Tuning summary

Young generation size selection

Response time priority application : Set as large as possible until it is close to the minimum response time limit of the system (choose according to the actual situation). In this case, the frequency of the young generation collection is also minimal. At the same time, reduce the number of objects reaching the old generation.

Throughput priority applications : Set as large as possible, possibly reaching the level of Gbit. Because there is no requirement for response time, garbage collection can be performed in parallel, which is generally suitable for applications with 8 CPUs or more.

Old age size selection

Response time priority applications : The older generation uses concurrent collectors, so its size needs to be carefully set, generally considering some parameters such as concurrent session rate and session duration . If the heap setting is small, it may cause memory fragmentation, high recovery frequency, and application suspension and use the traditional mark removal method; if the heap is large, longer collection time is required. The most optimized plan generally needs to refer to the following data to obtain:

\1. Concurrent garbage collection information

\2. Persistent generation concurrent collection times

\3. Traditional GC information

\4. The proportion of time spent on recycling of the young generation and the old generation

Reduce the time spent by the young and old generations, and generally improve the efficiency of the application

Throughput-first applications

Generally, throughput-first applications have a large young generation and a smaller old generation. The reason is that most of the short-term objects can be recycled as much as possible, the medium-term objects can be reduced, and the old generation can store long-term surviving objects.

Fragmentation problems caused by smaller heaps

Because the older generation of concurrent collectors use marking and clearing algorithms, they will not compress the heap. When the collector reclaims, it merges adjacent spaces so that they can be allocated to larger objects. However, when the heap space is small, after running for a period of time, "fragmentation" will appear. If the concurrent collector cannot find enough space, the concurrent collector will stop, and then use the traditional marking and cleaning methods for recycling. If "fragments" appear, the following configuration may be required:

\1. -XX:+UseCMSCompactAtFullCollection : When using the concurrent collector, enable compression for the old generation.

\2. -XX:CMSFullGCsBeforeCompaction=0 : When the above configuration is enabled, here is how many full GCs are set to compress the old generation


For more information, please pay attention to the official account: "Software King" , pay attention to not getting lost, Software King and his IT friends, share some of their technical insights and life stories.

Insert picture description here

Guess you like

Origin blog.csdn.net/wjg8209/article/details/109096708