Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you instructions about the configuration of JVM parameters. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

Heap setting-Xms: initial heap size-Xmx: maximum heap size-XX:NewSize=n: set the younger generation size-XX:NewRatio=n: sets the ratio of the younger generation to the older generation. For example, 3 means that the ratio of the young generation to the old generation is 1:3, and the young generation accounts for 1% of the sum of the young and old generations; if-Xmn is set, the configuration of-Xmn shall prevail. -XX:SurvivorRatio=n: the ratio of Eden region to two Survivor regions in the young generation. Notice that there are two in the Survivor area. For example: 3, means Eden:Survivor=3:2, a Survivor area occupies the entire young generation of 1/5-XX:MaxPermSize=n: set the persistent generation size-XX:MaxTenuringThreshold=n: set the maximum age of garbage. If set to 0, the younger generation will enter the older generation without going through the Survivor area. For more applications of the older generation, it can improve the efficiency. -XX:MetaspaceSize: the initial size allocated to the class metadata space in bytes (initial high water level on Oracle logical storage, the initial high-water-mark). This value is an estimate, and the value of MetaspaceSize is set too much to extend the garbage collection time. After garbage collection, the size of the class metadata space that causes the next garbage collection may become larger. -XX:MaxMetaspaceSize: the maximum value assigned to the class metadata space, beyond which Full GC is triggered. There is no limit to this value by default, but it should depend on the size of the system memory, and JVM will change this value dynamically. Collector Settings-XX:+UseSerialGC: set Serial Collector-XX:+UseParallelGC: set parallel Collector-XX:+UseParalledlOldGC: set parallel older Collector-XX:+UseConcMarkSweepGC: set concurrent Collector garbage Collection Statistics-XX:+PrintGC: output form: [GC 118250K-> 113543K (130112K), 0.0094143 secs] [Full GC 121376K-> 10414K (130112K), 0.0650971 secs]-XX:+PrintGCDetails: output form: [GC [DefNew: 8614K-> 781K (9088K) 0.0123035 secs] 118250K-> 113543K (130112K), 0.0124633 secs] [GC [DefNew: 8614K-> 8614K (9088K), 0.0000665 secs] [Tenured: 112761K-> 10414K (121024K), 0.0433488 secs] 121376K-> 10414K (130112K), 0.0436268 secs]-XX:+PrintGCTimeStamps-XX:+PrintGC:PrintGCTimeStamps can be mixed with the above two output forms: 11.851: [GC 98328K-> 93620K (130112K), 0.0082960 secs]-XX:+PrintGCApplicationConcurrentTime: print before each garbage collection Uninterrupted execution time of the program. Can be mixed with the above. Output form: Application time: 0.5291524 seconds-XX:+PrintGCApplicationStoppedTime: the time the program was paused during print garbage collection. Can be mixed with the above. Output form: Total time for which application threads were stopped: 0.0468229 seconds-XX:PrintHeapAtGC: print detailed stack information before and after GC. Parallel Collector setting-XX:ParallelGCThreads=n: sets the number of CPU used by the parallel collector when collecting. Number of threads collected in parallel. -XX:MaxGCPauseMillis=n: sets the maximum pause time for parallel collection-XX:GCTimeRatio=n: sets the percentage of garbage collection time to program running time. The formula is 1 / (1cm n)

# # concurrent Collector Settings

-XX:+CMSIncrementalMode: set to incremental mode. It is suitable for single CPU situation. -XX:ParallelGCThreads=n: the number of CPU used when the young generation of the concurrent collector is collected in parallel. Number of threads collected in parallel. Tuning and summarizing the size selection of the younger generation

Applications with priority response time: set it as large as possible until it approaches the minimum response time limit of the system (selected according to the actual situation). In this case, the frequency of collection of the younger generation is also the lowest. At the same time, reduce the number of people who reach the older generation.

Throughput priority applications: set up as large as possible, possibly to the extent of Gbit. Because there is no requirement for response time, garbage collection can be carried out in parallel, which is generally suitable for applications above 8CPU.

Choice of the size of the older generation

Response time priority applications: the older generation uses concurrent collectors, so its size needs to be set carefully, generally considering some parameters such as concurrent session rate and session duration. If the heap setting is small, it may cause memory fragmentation, high recycling frequency, and application pauses and use the traditional flag cleanup method; if the heap is large, it will take a long time to collect. For the most optimized scheme, you generally need to refer to the following data:

Concurrent garbage collection information

Number of concurrent collections of persistent generations

Traditional GC information

The proportion of time spent on recycling between the younger generation and the older generation

Reducing the time spent by the younger and older generations will generally improve the efficiency of the application.

Throughput priority applications

Generally speaking, applications with priority to throughput have a large younger generation and a younger older generation. The reason is that most of the short-term objects can be recycled as much as possible, reducing the number of medium-term objects, while the older generation can store long-term living objects.

Fragmentation problems caused by smaller heaps

Because the older generation of concurrent collectors use marking and clearing algorithms, the heap is not compressed. When the collector collects, 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, there will be "fragments". If the concurrent collector cannot find enough space, then the concurrent collector will stop and then recycle it using the traditional marking and clearing methods. If "fragmentation" occurs, you may need to configure as follows:

-XX:+UseCMSCompactAtFullCollection: enables compression of the older generation when using the concurrent collector.

-XX:CMSFullGCsBeforeCompaction=0: when the above configuration is enabled, how many times FullGC is set here to compress the older generation

The above is the configuration description of the JVM parameters shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.