Third, the option parameters explain
1, heap size settings
1 -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-Xmx 3550m: Set the maximum available memory of the JVM to 3550M.
-Xms 3550m: Set the JVM initial memory to 3550m. This value can be set to be the same as -Xmx to avoid the JVM reallocating memory after each garbage collection.
-Xmn 2g: Set the young generation size to 2G. The entire heap size = young generation size + age generation size + permanent generation size. The permanent generation has a fixed size of 64m, so increasing the young generation will reduce the size of the old generation. This value has a great impact on system performance. Sun officially recommends 3/8 of the entire heap.
-Xss 128k: Set the stack size for each thread . After JDK 5.0, the stack size of each thread is 1M, and the previous stack size of each thread is 256K. The memory size required for more application threads is adjusted. Under the same physical memory, reducing this value can generate more threads. However, the operating system has a limit on the number of threads in a process, and cannot be generated indefinitely. The empirical value is around 3000~5000.
2 -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
-XX:NewRatio =4: Set the ratio of the young generation (including Eden and the two Survivor areas) to the old generation (remove the permanent generation). Set to 4, the ratio of young to old generation is 1:4, and younger generation is 1/5 of the whole stack.
-XX:SurvivorRatio =4: Set the size ratio of the Eden area to the Survivor area in the young generation . Set to 4, the ratio of the two Survivor areas to an Eden area is 2:4, and one Survivor area accounts for 1/6 of the entire young generation.
-XX:PermSize : Sets the permanent value (perm gen) initial value. The default is 1/64 of physical memory.
-XX:MaxPermSize : Sets the maximum value of the persistent generation. 1/4 of physical memory.
– XX: MaxTenuringThreshold =0: Set the maximum age of garbage . If set to 0, the young generation object does not go through the Survivor area and directly enters the old generation. For applications with more old generations, efficiency can be improved. If this value is set to a larger value, the younger generation object will be replicated multiple times in the Survivor area, which will increase the survival time of the younger generation of the object and increase the generalization of recycling in the younger generation.
2, recycler selection
(1) Throughput priority parallel collector
1 -XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:+UseParallelGC : Select the garbage collector as a parallel collector . This configuration is only valid for younger generations . In the above configuration, the young generation uses concurrent collection, while the old generation still uses serial collection.
-XX:ParallelGCThreads =20: Configure the number of threads in the parallel collector , that is: how many threads are garbage collected together. This value is preferably configured to be equal to the number of processors.
2 -XX:+UseParallelOldGC
-XX:+UseParallelOldGC : Configures the old generation garbage collection method to be collected in parallel . JDK 6.0 supports parallel collection of old generations.
3 -XX:MaxGCPauseMillis=100
-XX:MaxGCPauseMillis =100: Set the maximum time for each young generation garbage collection . If this time is not met, the JVM will automatically adjust the young generation size to meet this value.
4 -XX:+UseAdaptiveSizePolicy
-XX:+UseAdaptiveSizePolicy : When this option is set, the parallel collector will automatically select the size of the young generation area and the corresponding proportion of the Survivor area to achieve the minimum corresponding time or collection frequency specified by the target system. This value is recommended when using the parallel collector. , always open.
(2) Response time priority concurrent collector
1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC : Set the old generation to concurrent collection . After configuring this in the test, the configuration of -XX:NewRatio=4 is invalid, and the reason is unknown. Therefore, at this time, the size of the young generation is best set with -Xmn.
-XX:+UseParNewGC : Set the young generation to collect in parallel. Can be used simultaneously with CMS collection. JDK5.0 or above, the JVM will be set according to the system configuration, so there is no need to set this value.
2 -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction : Since the concurrent collector does not compress or organize the memory space, it will generate “fragmentation” after running for a period of time, which reduces the running efficiency. This value sets how many times the GC is run to compress and organize the memory space.
-XX:+UseCMSCompactAtFullCollection : Opens the compression of the old generation. May affect performance, but can eliminate fragmentation
3. Auxiliary information
The JVM provides a number of command line arguments to print information for debugging purposes. There are mainly the following:
1 -XX:+PrintGC
Output form:
[GC 118250K->113543K (130112K), 0.0094143 secs]
[Full GC 121376K->10414K (130112K), 0.0650971 secs]
2 -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]
3 -XX:+PrintGCTimeStamps -XX:+PrintGC:PrintGCTimeStamps can be mixed with the above two
Output form:
11.851: [GC 98328K->93620K (130112K), 0.0082960 secs]
4 -XX:+PrintGCApplicationConcurrentTime: Prints the execution time of the program before it is garbage collected. Can be mixed with the above
Output form:
Application time: 0.5291524 seconds
5 -XX:+PrintGCApplicationStoppedTime: Prints the time the program was paused during garbage collection. Can be mixed with the above
Output form:
Total time for which application threads were stopped: 0.0468229 seconds
6 -XX: PrintHeapAtGC: Print detailed stack information before and after GC
Output form:
34.702: [GC {Heap before gc invocations=7:
Def new generation total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)
Eden space 49152K, 99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)
From space 6144K, 55% used [0x221d0000, 0x22527e10, 0x227d0000)
To space 6144K, 0% used [0x21bd0000, 0x21bd0000, 0x221d0000)
Tenured generation total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)
The space 69632K, 3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)
Compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
The space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
Ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
Rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
34.735: [DefNew: 52568K->3433K (55296K), 0.0072126 secs] 55264K->6615K (124928K) Heap after gc invocations=8:
Def new generation total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)
Eden space 49152K, 0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)
From space 6144K, 55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)
To space 6144K, 0% used [0x221d0000, 0x221d0000, 0x227d0000)
Tenured generation total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)
The space 69632K, 4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)
Compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
The space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
Ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
Rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
}
, 0.0757599 secs]
7 -Xloggc:filename: Used in conjunction with the above, log related log information to a file for analysis.
Fourth, common configuration summary
1, heap settings
1 -Xms: initial heap size
2 -Xmx: maximum heap size
3 -XX:NewSize=n: set the size of the young generation
4 -XX:NewRatio=n: Set the ratio of young and old generations. For example, it is 3, indicating that the ratio of young to old is 1:3, and the young generation accounts for 1/4 of the young generation.
5 -XX: SurvivorRatio=n: The ratio of the Eden area to the two Survivor areas in the young generation. Note that there are two in the Survivor area. Such as: 3, said Eden: Survivor = 3: 2, a Survivor area accounted for 1/5 of the entire young generation
6 -XX:MaxPermSize=n: Set the permanent generation size
2, collector settings
1 -XX:+UseSerialGC: Set the serial collector
2 -XX:+UseParallelGC: Set the parallel collector
3 -XX:+UseParalledlOldGC: Set parallel old generation collector
4 -XX:+UseConcMarkSweepGC: Set Concurrent Collector
3, garbage collection statistics
1 -XX:+PrintGC
2 -XX:+PrintGCDetails
3 -XX:+PrintGCTimeStamps
4 -Xloggc:filename
4, parallel collector settings
1 -XX:ParallelGCThreads=n: Sets the number of CPUs used for parallel collector collection. Collect threads in parallel.
2 -XX:MaxGCPauseMillis=n: Set the maximum pause time for parallel collection
3 -XX:GCTimeRatio=n: Set the garbage collection time as a percentage of the program runtime. The formula is 1/(1+n)
5, concurrent collector settings
1 -XX:+CMSIncrementalMode: Set to incremental mode. Applicable to single CPU situations.
2 -XX:ParallelGCThreads=n: Set the number of CPUs used by the concurrent collector collection method for parallel collection. Collect threads in parallel.
V. Summary of tuning
1, young generation size selection
1 Response time-first application: Set as large as possible until the system’s minimum response time limit (according to the actual situation). In this case, the frequency of young generation collections is also minimal. At the same time, reduce the number of people reaching the old generation.
2 throughput-priority applications: as large as possible, may reach the level of Gbit. Because there is no requirement for response time, garbage collection can be performed in parallel, and is generally suitable for applications with more than 8 CPUs.
2, the age of old generation choice
1 Response time-first application: The old generation uses the concurrent collector, so its size needs to be carefully set, generally considering some parameters such as concurrent session rate and session duration. If the heap is set small, it can cause memory fragmentation, high recovery frequency, and application pauses using traditional markup cleanup; if the heap is large, it takes longer to collect. The optimized solution generally needs to be obtained by referring to the following data:
Concurrent garbage collection information
Persistent generation concurrent collections
Traditional GC information
Proportion of time spent on recycling young and old generations
Reducing the time spent by young and old generations generally increases the efficiency of the application
2 Throughput-first applications: General throughput-first applications have a large young generation and a smaller older generation. The reason is that this way, most of the short-term objects can be recovered as much as possible, and the medium-term objects can be reduced.
3. Fragmentation problems caused by smaller heaps
Because the older collector’s concurrent collector uses the markup and cleanup algorithms, the heap is not compressed. When the collector recycles, it merges the adjacent spaces so that it can be assigned to larger objects. However, when the heap space is small, after running for a while, “fragmentation” will occur. If the concurrent collector cannot find enough space, the concurrent collector will stop and then use traditional markup and cleanup methods for recycling. If “fragmentation” occurs, you may need to do the following:
1 -XX:+UseCMSCompactAtFullCollection: Turns on compression for the old generation when using the concurrent collector.
2 -XX:CMSFullGCsBeforeCompaction=0: In the case where the above configuration is enabled, how many times the Full GC is set here, the old generation is compressed.
Six, related concepts
1, generational garbage recycling details
(1) Young (young generation)
The young generation is divided into three districts . One Eden area, two Survivor areas . Most of the objects are generated in the Eden area. When the Eden area is full, the surviving objects will be copied to the Survivor area (one of the two). When the Survivor area is full, the surviving objects in this area will be copied to another Survivor area, when the Survivor goes When it is full, the object copied from the first Survivor area and still alive at this time will be copied “Tenured”. It should be noted that the two areas of Survivor are symmetrical and have no relationship, so there may be objects copied from Eden and objects copied from the previous Survivor in the same area, and only the first one copied to the old district. The object that Survivor came over. Moreover, there is always one empty in the Survivor area.
(2) Tenured (old generation)
The old generation stores objects that survive from the young generation . In general, older generations store objects that have a long life span.
(3) Perm (persistent generation)
Used to store static files , Java classes, methods, and more. Persistent generation has no significant impact on garbage collection, but some applications may dynamically generate or call some classes, such as Hibernate, etc. In this case, you need to set a larger persistent generation space to store the new classes in the running process. The persistent generation size is set by -XX:MaxPermSize=.
2, GC type
There are two types of GC: Scavenge GC and Full GC.
(1) Scavenge GC
In general, when a new object is generated and the Eden application space fails, the Scavenge GC is triggered, the heap Eden area is GC, the non-viable objects are cleared, and the surviving objects are moved to the Survivor area. Then organize the two areas of Survivor.
(2) Full GC
Organize the entire heap , including Young, Tenured, and Perm. Full GC is slower than the Scavenge GC, so you should minimize the Full GC . The Full GC may be caused by the following reasons:
Tenured is filled
Perm domain is filled
System.gc() is called to be called
Dynamic change of Heap’s domain allocation strategies after the last GC
3, garbage collector
There are three main types of collectors: serial collectors, parallel collectors, and concurrent collectors.
(1) Serial collector
Use single-threaded processing of all garbage collection work, because it does not require multi-threaded interaction, so it is more efficient. However, the advantages of multiprocessors cannot be used, so this collector is suitable for single processor machines. Of course, this collector can also be used on multiprocessor machines with small data volumes ( around 100M ). It can be opened with -XX:+UseSerialGC .
(2) Parallel collector
Parallel garbage collection for younger generations can reduce garbage collection time. Generally used on multi-threaded multiprocessor machines. Open with -XX:+UseParallelGC . The parallel collector was introduced in the J6SE5.0 sixth 6 update, and was enhanced in Java SE 6.0 – it can be collected in parallel for older generations. If the old generation does not use concurrent collection, it uses single-threaded garbage collection , which will restrict the expansion capability. Open with -XX:+UseParallelOldGC .
Use -XX:ParallelGCThreads=Set the number of threads for parallel garbage collection . This value can be set equal to the number of machine processors .
This collector can be configured as follows:
Maximum garbage collection pause: Specify the maximum pause time for garbage collection, specified by -XX:MaxGCPauseMillis= . In milliseconds. If this value is specified, the heap size and garbage collection related parameters are adjusted to the specified value. Setting this value may reduce the throughput of your application.
Throughput: The ratio of throughput to garbage collection time and non-garbage recovery time is set by -XX:GCTimeRatio= , and the formula is 1/(1+N) . For example, when -XX:GCTimeRatio=19, it means 5% of the time is used for garbage collection. The default is 99, which is 1% of the time for garbage collection.
(3) Concurrent collector
It can guarantee that most of the work is carried out concurrently (the application does not stop), and garbage collection is only suspended for a small amount of time. This collector is suitable for medium and large-scale applications with high response time requirements. Open with -XX:+UseConcMarkSweepGC .
The concurrent collector mainly reduces the pause time of the old generation. He uses a separate garbage collection thread to track the reachable objects without stopping the application. In each old generation garbage collection cycle, the concurrent collector will briefly pause the entire application at the beginning of the collection, and will pause again during the collection. The second pause will be slightly longer than the first one, during which multiple threads will perform garbage collection at the same time.
The concurrent collector uses the processor for a short pause . On a system with N processors, the concurrent collection part is recovered using K/N available processors, typically 1<=K<=N/4 .
Using a concurrent collector on a host with only one processor, a shorter pause can also be achieved by setting to incremental mode .
Floating garbage : Since garbage is collected while the application is running, some garbage may be generated when the garbage collection is completed, which results in “Floating Garbage”, which needs to be recycled in the next garbage collection cycle. Therefore, concurrent collectors typically require 20% of the reserved space for these floating garbage.
Concurrent Mode Failure : The concurrent collector collects when the application is running, so you need to ensure that the heap has enough space for the program to use during the garbage collection. Otherwise, the garbage collection is not completed and the heap space is full. In this case, “concurrency mode failure” will occur, and the entire application will be suspended for garbage collection.
Start Concurrent Collector : Because concurrent collection is collected while the application is running, you must ensure that there is enough memory space for the program to use before the collection is complete, otherwise “Concurrent Mode Failure” will occur. Start concurrent collection by setting -XX:CMSInitiatingOccupancyFraction= Specifying how many remaining heaps there are
(4) Summary
1 serial processor:
— Applicable situation: The data volume is relatively small (about 100M) ; the application under single processor and no response time.
— Disadvantages: only for small applications
2 parallel processor:
— Applicable situation: “High requirements for throughput” , multi-CPU, medium and large-scale applications that do not require application response time. Examples: background processing, scientific computing.
— Disadvantages: Application response time may be longer
3 concurrent processor:
— Applicable situation: “High requirements for response time” , multi-CPU, medium and large-scale applications with high requirements on application response time. For example: web server / application server, telecommunications exchange, integrated development environment.
4, the basic recovery algorithm
(1) Reference Counting
Older recycling algorithm. The principle is that this object has a reference, which is to increment a count, and to delete a reference to reduce a count. In garbage collection, only objects with a count of 0 are collected. The most deadly of this algorithm is the inability to handle circular references.
(2) Mark-Sweep (Mark-Sweep)
This algorithm is executed in two phases. The first stage marks all referenced objects starting from the reference root node, and the second stage traverses the entire heap, clearing the unmarked objects. This algorithm needs to pause the entire application and, at the same time, generate memory fragmentation.
(3) Copying
This algorithm divides the memory space into two equal regions, using only one of the regions at a time. In garbage collection, traverse the current usage area and copy the object in use to another area. The secondary algorithm only processes the objects in use at a time, so the copying cost is relatively small, and the corresponding memory can be sorted after copying in the past, but the “fragmentation” problem occurs. Of course, the shortcoming of this algorithm is also obvious, that is, it requires twice the memory space.
(4) Mark-Compact
This algorithm combines the advantages of both the “mark-clear” and “copy” algorithms. It is also divided into two phases. The first phase marks all referenced objects from the root node. The second phase traverses the entire heap, clears the unlabeled objects and “compresses” the surviving objects into one of the heaps, and discharges them in order. This algorithm avoids the “flag-clear” fragmentation problem and also avoids the space problem of the “copy” algorithm.
(5) Incremental Collecting
Implement a garbage collection algorithm that performs garbage collection while the application is running. I don’t know why the collector in JDK 5.0 does not use this algorithm.
(6) Generational Collecting
Based on the garbage collection algorithm after analyzing the life cycle of the object. The objects are divided into young, old, and permanent generations, and different algorithms (one of the above methods) are used to recover objects of different life cycles. The current garbage collector (starting with J2SE 1.2) uses this algorithm.
Recent Comments