JVM Tuning Summary

First, related concepts

Basic Recovery Algorithm

1. reference count (Reference counting)
   older recycling algorithms. The principle is that this object has a reference, that is to add a count, delete a reference and reduce a count. When garbage collection, only objects with a collection count of 0 are used. The most deadly of this algorithm is the inability to handle circular references.
2. Tag-Clear (Mark-sweep)
   This algorithm executes in two phases. The first stage marks all referenced objects starting from the reference root node, the second stage traverses the entire heap, and the unmarked objects are purged. This algorithm needs to pause the entire application while generating memory fragmentation.
3. Replication (Copying)
   This algorithm delimits the memory space as two equal areas, using only one of the regions at a time. During garbage collection, iterate through the current usage area and copy the objects in use to another area. The secondary algorithm only processes objects that are in use at a time, so the cost of replication is small, and the memory can be collated in the past, but there is a "fragmentation" problem. Of course, the disadvantage of this algorithm is also very obvious, is to need twice times the memory space.
4. Tag-organize (mark-compact)
   This algorithm combines the advantages of the "mark-clear" and "copy" two algorithms. It is also divided into two stages, the first phase marks all referenced objects starting from the root node, the second stage traverses the entire heap, clears the unlabeled objects and "compresses" the surviving objects into one of the heaps, and discharges them sequentially. This algorithm avoids the "mark-erase" fragmentation problem and avoids the space problem of the "copy" algorithm.
5. Incremental Collection (Incremental collecting)
   implements the garbage collection algorithm, that is, garbage collection while the app is in progress. Do not know what reason the collector in JDK5.0 does not use this algorithm.
6. Generational (generational collecting)
   is based on the garbage collection algorithm that is derived from the object life cycle analysis. Divide the objects into young, old, and persistent generations, using different algorithms (one of these methods) for different life cycle objects. The current garbage collector (starting with j2se1.2) uses this algorithm.

sub-generational garbage collection details

As shown, it is distributed across generations in the Java heap.

1. Young (Young Generation)
   The young generation is divided into three districts. One Eden area, two survivor districts. Most objects are generated in the Eden area. When the Eden Zone is full, the surviving objects will be copied to the Survivor area (one of two), and when the survivor area is full, the surviving objects of this area will be copied to another survivor area, when the survivor is full, Objects that are copied from the first survivor area and that are still alive will be duplicated in the old Age zone (tenured). It should be noted that the two areas of the survivor are symmetrical and have no relationship, so the same area may exist at the same time from Eden copied objects, and from the previous survivor copied objects, and copied to the old quarter only from the first survivor to come over the object. Moreover, there is always an empty survivor area.
2. tenured (Old Generation)
   Older generations store objects that survive from younger generations. In general, older generations are storing long-term objects.
3. Perm (persistent generation)
   used to store static files, now Java classes, methods, and so on. The persistence generation has no significant impact on garbage collection, but some applications may dynamically generate or invoke some classes, such as Hibernate, at which point a large, persistent generation space is required to store the new class in these runs. The persistent generation size is set by-xx:maxpermsize=.

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 when the Eden application space fails, it is good to trigger the scavenge GC, the heap Eden Zone is GC, the non-surviving objects are cleared, and the surviving objects are moved to the survivor area. Then tidy up the two districts of survivor.
2. Full GC
   Organize the entire heap, including young, tenured and perm. The full GC is slower than the scavenge GC, so the full GC should be minimized as much as possible. The full GC may be caused by the following reasons:
• Tenured was written full
• Perm field is full
• System.GC () is displayed call
• Dynamic changes in the domain allocation policy of the heap after the last GC

presentation of the generational garbage collection process

second, the garbage collector

The current collector has three main types: serial collector, parallel collector, and concurrent collector .

Serial collector

Use single-threaded processing for all garbage collection work, because there is no need for multi-threaded interaction, so the efficiency is high. However, it is also not possible to use the advantages of multiple processors, so this collector is suitable for single processor machines. Of course, this collector can also be used on multiprocessor machines with a small amount of data (around100M ). Can be opened using -XX:+USESERIALGC .

Parallel collector

Parallel garbage collection for younger generations, so you can reduce garbage collection time. Typically used on multi-threaded multiprocessor machines. Use -XX:+USEPARALLELGC. Open. The parallel collector, introduced in the j2se5.0 66th update, has been enhanced in Java SE6.0--the ability to heap older generations for parallel collection. If the older generation does not use concurrent collections, it is a single thread for garbage collection and therefore restricts the ability to scale. Open with -XX:+USEPARALLELOLDGC .

1. Use -xx:parallelgcthreads= to set the number of threads for parallel garbage collection. This value can be set equal to the number of machine processors .

2. This collector can be configured as follows:

§ Max garbage collection pause: Specifies the maximum pause time for garbage collection, as specified by -xx:maxgcpausemillis= . is milliseconds. If this value is specified, the heap size and garbage collection related parameters are adjusted to reach the specified value . Setting this value may reduce the throughput of your app.

§ Throughput: throughput is the ratio of garbage collection time to non-garbage collected time , set by -xx:gctimeratio= , with a formula of 1/(1+n). For example,-xx:gctimeratio=19 indicates that 5% of the time is used for garbage collection. The default is 99, which is 1% of the time used for garbage collection.

Concurrent Collectors

Can ensure that most of the work is concurrent (the application does not stop), garbage collection only pause for a very small amount of time, this collector is suitable for the response time requirements of high-scale applications. Open with -xx:+useconcmarksweepgc .

1. The concurrent collector mainly reduces the time of the old generation to pause, and he uses a separate garbage collection thread to track the objects that can be reached without stopping the application. In each old generation garbage collection cycle, the concurrency collector briefly pauses the entire application during the collection, and pauses it again in the collection. The second pause is slightly longer than the first, during which multiple threads are garbage collected at the same time.

2. The concurrent collector uses the processor for a short pause time . On a system of N processors, the concurrent collection portion is recycled using k/n available processors, typically 1<=K<=N/4.

3. with a concurrent collector on a host with only one processor , a short pause time can also be set to incremental mode mode.

4. floating garbage : Because of the garbage collection while the application is running, some rubbish may be generated when the garbage collection is completed, which results in "floating garbage", which needs to be reclaimed at the next garbage collection cycle. Therefore, concurrent collectors typically require 20% of reserved space for these floating garbage.

5. Concurrent Mode Failure: The concurrent collector collects when the application is running, so it is necessary to ensure that the heap has sufficient space for the program to use during the garbage collection period, otherwise, the garbage collection is not completed and the heap space is first full. In this case, a "concurrency mode failure" will occur and the entire app will be paused for garbage collection.

6. Start the concurrency collector : Because concurrent collections are collected when the app is running, you must ensure that there is enough memory space for the program to use before the collection is complete, or "Concurrent Mode Failure" will appear. To start a concurrent collection when you specify how many remaining heaps are -xx:cmsinitiatingoccupancyfraction= by setting the

2. Summary

o Serial Processor:
-Applicable: Small data volume (around 100M), single processor and no response time requirements of the application.
--Cons: Only for small applications

o Parallel Processor:
--Application: "High throughput Requirements", multi-CPU, application response time is not required for medium and large-scale applications. Examples: Background processing, scientific calculation.
--Cons: Application response time may be longer

o Concurrent Processors:
-Application: "High response time Requirements", multi-CPU, the application response time has a high demand for medium and large-scale applications. Examples: Web server/Application server, Telecom Exchange, integrated development environment.

iii. Common Configuration examples

2. Heap Size Settings
   the maximum heap size in the JVM has three limitations: the data Model (32-BT or 64-bit) of the associated operating system, the system's available virtual memory limits, and the available physical memory limits for the system. Under the 32-bit system, the 1.5g~2g;64 is generally limited to memory unrestricted for the operating system. I test under Windows Server 2003 System, 3.5G physical memory, JDK5.0, Max can be set to 1478m.
   Typical settings:
• Java -xmx3550m-xms3550m-xmn2g -xss128k
  -xmx3550m: Sets the maximum available memory for the JVM to 3550M.
  -xms3550m: Set the JVM initial memory to 3550m. This value can be set to the same as-xmx to avoid the JVM reallocating memory after each garbage collection completes.
  -xmn2g: Set the young generation size to 2G. the entire heap size = younger generation size + old generation size + persistent generation size . The permanent average fixed size is 64m, so increasing the younger generation will reduce the size of older generations. This value has a large impact on system performance, and Sun's official recommendation is 3/8 for the entire heap.
  -xss128k: Sets the stack size for each thread. After JDK5.0, each thread has a stack size of 1M, before each thread has a stack size of 256K. The size of the memory required for the more applied threads to be adjusted. In the same physical memory, reducing this value can generate more threads. However, the operating system of the number of threads within a process is still limited, can not be generated indefinitely, the empirical value of 3000~5000 around.
• java-xmx3550m-xms3550m-xss128k -xx:newratio=4-xx:survivorratio=4-xx:maxpermsize=16m-xx:maxtenuringthreshold =0
  -xx:newratio=4: Sets the ratio of the young generation (including Eden and the two survivor zone) to the old generation (except for the persistent generation). Set to 4, the ratio of the young generation to the old generation is 1:4, and the younger generation takes up 1/5 of the entire stack.
  -xx:survivorratio=4: Sets the ratio of the size of Eden and survivor in the younger generation. Set to 4, the ratio of two survivor to one Eden area is 2:4, and a survivor area represents 1/6 of the entire young generation.
  -xx:maxpermsize=16m: Set the persistent generation size to 16m.
  -xx:maxtenuringthreshold=0: Sets the maximum age for garbage. if set to 0, then the young generation object does not go through the survivor area, directly into the old generation . For older generations of more applications, can improve efficiency. If this value is set to a larger value, the younger generation objects are duplicated multiple times in the Survivor area, which increases the survival time of the object's younger generations , increasing the introduction of being recycled in the younger generation.
4. Collector Selection
   the JVM gives three choices: the serial collector, the parallel collector, the concurrent collector , but the serial collector is only available for small amounts of data, so the choice here is primarily for the parallel collector and the concurrency collector. By default, JDK5.0 used a serial collector before, and if you want to use a different collector, you need to add the appropriate parameters at startup. After JDK5.0, the JVM is judged based on the current system configuration.

2. throughput-First parallel collector
   As mentioned above, the parallel collector is mainly aimed at reaching a certain throughput, and is suitable for science and technology and background processing.
   Typical configuration :
• java-xmx3800m-xms3800m-xmn2g-xss128k -xx:+useparallelgc-xx:parallelgcthreads=20
  STRONG>-XX:+USEPARALLELGC : Select the garbage collector as the parallel collector. This configuration is valid only for younger generations. In this configuration, the younger generation uses concurrent collection, while the older generation still uses serial collection.
  -xx:parallelgcthreads=20 : Configures the number of threads for a parallel collector, that is, how many threads are garbage collected together. This value is best configured to be equal to the number of processors.
• java-xmx3550m-xms3550m-xmn2g-xss128k-xx:+useparallelgc-xx:parallelgcthreads=20 -XX:+ USEPARALLELOLDGC
  -XX:+USEPARALLELOLDGC : Configure the old Generation garbage collection method for parallel collection. JDK6.0 supports parallel collection of older generations.
• java-xmx3550m-xms3550m-xmn2g-xss128k-xx:+useparallelgc  -xx:maxgcpausemillis=100
  -XX: MAXGCPAUSEMILLIS=100: Sets the maximum time for each young generation of garbage collection, and if this time is not met, the JVM automatically adjusts the younger generation size to meet this value.
• java-xmx3550m-xms3550m-xmn2g-xss128k-xx:+useparallelgc -xx:maxgcpausemillis=100 -XX:+ Useadaptivesizepolicy
  -xx:+useadaptivesizepolicy : When this option is set, the parallel collector automatically selects the size of the younger generation and the corresponding Survivor area scale. This value is recommended to be turned on when using a parallel collector to achieve the minimum corresponding time specified by the target system, or the frequency of collection.
4. Concurrency collector with response time Precedence
   As mentioned above, the concurrency collector is mainly to ensure the response time of the system, reduce the time of the garbage collection downtime. It is suitable for application server, telecom field and so on.
   Typical configuration :
• Java-xmx3550m-xms3550m-xmn2g-xss128k-xx:parallelgcthreads=20 -XX:+USECONCMARKSWEEPGC-XX:+USEPARNEWGC
  -XX:+USECONCMARKSWEEPGC: Set old age on behalf of concurrent collection. After configuring this in the test, the configuration of the-xx:newratio=4 is invalid for unknown reasons. Therefore, at this time the younger generation size is best set with-XMN.
  -XX:+USEPARNEWGC: Set Young on behalf of the parallel collection. Can be used concurrently with CMS collection. JDK5.0 above, the JVM will set itself according to the system configuration, so it is no longer necessary to set this value.
• JAVA-XMX3550M-XMS3550M-XMN2G-XSS128K-XX:+USECONCMARKSWEEPGC -xx:cmsfullgcsbeforecompaction=5-xx:+ Usecmscompactatfullcollection
  -xx:cmsfullgcsbeforecompaction: Because the concurrent collector does not compress and defragment the memory space, it can produce "fragmentation" after a period of time, which makes the operation less efficient. This value sets how many times a GC is run to compress and defragment the memory space.
  -xx:+usecmscompactatfullcollection: Turn on compression for older generations. Performance may be affected, but fragmentation can be eliminated
3. Ancillary information
   The JVM provides a number of command-line arguments to print information for debugging purposes. There are mainly the following:

• -xx:+printgc
  output Form : [GC 118250k->113543k (130112K), 0.0094143 secs]

[Full GC 121376k->10414k (130112K), 0.0650971 secs]

• -xx:+printetails
  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 s ECS] 121376k->10414k (130112K), 0.0436268 secs]

• -xx:+printgctimestamps -xx:+printgc:printgctimestamps can be mixed with the above two
  Output form:11.851: [GC 98328k->93620k (130112K), 0.0082960 secs]
• -xx:+printgcapplicationconcurrenttime: The execution time of the program is not interrupted before each garbage collection is printed. Can be mixed with the above
  Output form:application time:0.5291524 seconds
• -xx:+printgcapplicationstoppedtime: The time the program was paused during the print garbage collection. Can be mixed with the above
  Output form: Total time forwhich application threads were stopped:0.0468229 seconds
• -XX:PRINTHEAPATGC: detailed stack information before and after the GC is printed
  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]
• -xloggc:filename: In conjunction with the above several, log information to the file for analysis.
4. Common configuration rollups

1. Heap Settings
• -xms: initial heap Size
• -xmx: Maximum heap Size
• -xx:newsize=n: Setting the young generation size
• -xx:newratio=n: Sets the ratio of the younger generation to the older generation. such as: 3, the ratio of the young generation and the old generation is 1:3, the young generation of the entire young generation of old generation and 1/4
• -xx:survivorratio=n: The ratio of Eden in the young generation to the two survivor districts. Note that there are two survivor districts. such as: 3, indicating Eden:survivor=3:2, a Survivor area accounted for the entire young generation of 1/5
• -xx:maxpermsize=n: Setting the persistent generation size
3. Collector Settings
• -XX:+USESERIALGC: Setting up the serial collector
• -XX:+USEPARALLELGC: Setting up a parallel collector
• -XX:+USEPARALLEDLOLDGC: Setting up a parallel old generation collector
• -XX:+USECONCMARKSWEEPGC: Setting the concurrency Collector
5. Garbage collection Statistics
• -XX:+PRINTGC
• -xx:+printetails
• -xx:+printgctimestamps
• -xloggc:filename
7. Parallel collector settings
• -xx:parallelgcthreads=n: Sets the number of CPUs to use when the parallel collector is collected. The number of parallel collection threads.
• -xx:maxgcpausemillis=n: Set maximum pause time for parallel collection
• -xx:gctimeratio=n: Sets the percentage of time that garbage collection takes to run the program. The formula is 1/(1+n)
9. Concurrent collector Settings
• -xx:+cmsincrementalmode: Set to incremental mode. Applies to single CPU conditions.
• -xx:parallelgcthreads=n: Set the concurrency collector the number of CPUs used by the young generation collection method for parallel collection. The number of parallel collection threads.

Iv. Summary of tuning

1. Young Generation Size selection
• Response Time-First application : as large as possible until the minimum response time limit of the system is approached (depending on the actual situation). In such cases, the frequency at which the young generation collects occurs is also minimal. At the same time, reduce the reach of older generations of objects.
• throughput-First application : as large as possible, may reach Gbit degree. Because there is no requirement for response time, garbage collection can be done in parallel, generally suitable for applications over 8CPU.
2. elder Generation Size selection
• Response Time-first application : Older generations Use the concurrency collector, so the size needs to be set carefully, and some parameters, such as concurrent session rate and session duration , are generally considered. If the heap setting is small, it can result in memory fragmentation, high recovery frequency, and application pauses using traditional markup cleanup, and if the heap is large, a longer collection time is required. The most optimized scenario is generally referred to the following data:
• Concurrent garbage Collection Information
• Persistent generation concurrent Collection times
• Traditional GC Information
• The proportion of time spent in the collection of young and old generations

Reducing the time spent in younger generations and older generations will generally increase the efficiency of your application

• throughput-First applications : General throughput priority applications have a very large young generation and a smaller old generation. The reason for this is that the majority of short-term objects can be recovered as much as possible, reducing medium-term objects, while older generations store long-lived objects.
2. Fragmentation problems caused by smaller heaps
   The heap is not compressed because the old generation of concurrent collectors uses tags and clears the algorithm. When the collector recycles, he merges the adjacent space so that it can be assigned to a larger object. However, when the heap space is small, after a period of time, "fragmentation" occurs, if the concurrent collector does not find enough space, then the concurrent collector will stop, and then use the traditional token, purging method for recycling. If "Fragmentation" occurs, you may need to configure the following:
• -xx:+usecmscompactatfullcollection: When using the concurrency collector, the compression of older generations is turned on.
• -xx:cmsfullgcsbeforecompaction=0: When the above configuration is on, how many times the full GC is set, the old generation is compressed

v. References

• Java Theory and Practice: A Brief History of garbage collection
• Java SE 6 Hotspot[tm] Virtual machine garbage Collection Tuning
• Improving Java application performance and Scalability by reducing garbage Collection times and Sizing Memory Using JDK 1. 4.1
• Hotspot Memory Management Whitepaper
• Java Tuning White Paper
• Diagnosing a garbage Collection problem
• Java HotSpot VM Options
• A Collection of the JVM Options
• Frequently asked Questions about garbage Collection in the Hotspottm JAVATM Virtual machine

JVM Tuning Summary