JVM Parameter Configuration
1.JVM parameter table
1.1 Table of common Parameters
| The parameter name | meaning | The default value | |
|---|---|---|---|
| -Xms | Initial heap size | 1/64 of physical memory (<1GB) | By default (the MinHeapFreeRatio parameter can be adjusted), when the free heap is less than 40%, the JVM increases the heap to the maximum limit of -xmx. |
| -Xmx | Maximum heap size | 1/4 of physical memory (<1GB) | By default (the MaxHeapFreeRatio parameter can be adjusted) when free heap memory is greater than 70%, the JVM reduces the heap to the minimum limit of -xms |
| -Xmn | Young generation size (1.4or lator) | Pay attention to: The size here is (Eden + 2 survivor space). This is different from the New Gen shown in Jmap-heap. Total heap size = young generation size + Old generation size + persistent generation size. When you increase the young generation, you decrease the size of the old generation. This value has a significant impact on system performance. Sun officially recommends setting it to 3/8 of the entire heap | |
| -XX:NewSize | Set young generation size (for 1.3/1.4) | ||
| -XX:MaxNewSize | Maximum young generation (for 1.3/1.4) | ||
| -XX:PermSize | Set the initial perm gen value | 1/64 of physical memory | |
| -XX:MaxPermSize | Set the maximum number of persistent generations | One fourth of the physical memory | |
| -Xss | Stack size per thread | After JDK5.0, the stack size of each thread is 1M. Before JDK5.0, the stack size of each thread is 256K. The size of memory required by more applied threads is adjusted. Reducing this value generates more threads for the same physical memory. However, the operating system has a limit on the number of threads in a process, which can not be generated indefinitely. The experience value is about 3000~5000. Generally, small applications, if the stack is not very deep, should be 128K enough. This option has a significant impact on performance and requires rigorous testing. (Principal) The interpretation is very similar to that of Threadstacksize. The official document does not seem to explain this. There is a sentence in the forum :” -Xss is translated in a VM flag named Threadstacksize “. Generally, this value will do. | |
| -*XX:ThreadStackSize | Thread Stack Size | (0 means default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux AMD64:1024 (was 0 in 5.0 and earlier); All others 0. | |
| -XX:NewRatio | Ratio of young generation (including Eden and two Survivor zones) to old generation (excluding persistent generation) | -xx :NewRatio=4 Indicates that the ratio of the young generation to the old generation is 1:4. The young generation occupies 1/5 of the entire stack. If Xms=Xmx and Xmn is set, this parameter does not need to be set. | |
| -XX:SurvivorRatio | Size ratio of Eden zone to Survivor zone | If set to 8, the ratio of two Survivor zones to one Eden zone is 2:8, and one Survivor zone accounts for 1/10 of the whole young generation | |
| -XX:LargePageSizeInBytes | Do not set the size of the memory page to too large, which will affect the Perm size | =128m | |
| -XX:+UseFastAccessorMethods | Quick optimization of primitive types | ||
| -XX:+DisableExplicitGC | Closure System. The gc () | This parameter requires rigorous testing | |
| -XX:MaxTenuringThreshold | Maximum age of garbage | If set to 0, the young generation object passes through the Survivor zone and goes directly to the old generation. For the older generation of more applications, can improve efficiency. If set to a large value, the young generation object will be copied in Survivor zones many times, increasing the lifetime of the object in the young generation and increasing the probability that it will be collected in the young generation. This parameter is only valid for serial GC. | |
| -XX:+AggressiveOpts | To speed up compilation | ||
| -XX:+UseBiasedLocking | Locking mechanism performance improvements | ||
| -Xnoclassgc | Disable garbage collection | ||
| -XX:SoftRefLRUPolicyMSPerMB | Lifetime of a SoftReference in the free space of each MB heap | 1s | softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap |
| -XX:PretenureSizeThreshold | Objects over size are allocated directly in the generation | 0 | The Parallel Avenge Avenge another situation that is allocated directly in the older generation is a large array object that has no external reference objects in it. |
| -XX:TLABWasteTargetPercent | Percentage of TLAB in Eden District | 1% | |
| -XX:+CollectGen0First | Whether YGC precedes FullGC | false |
1.2 Parameters related to parallel collector
| -XX:+UseParallelGC | Parallel MSC for Full GC | Select the garbage collector as a parallel collector. This configuration is valid only for the young generation. That is, under the above configuration, the young generation uses concurrent collection, while the old generation still uses serial collection. | |
|---|---|---|---|
| -XX:+UseParNewGC | Set concurrent collection for the young user | You can use JDK5.0 or above in conjunction with the CMS collection, and the JVM will set it itself based on system configuration, so you do not need to set this value | |
| -XX:ParallelGCThreads | Number of threads for the parallel collector | This value is best configured to equal the number of processors and also applies to CMS | |
| -XX:+UseParallelOldGC | Parallel Compacting garbage Collection for the elderly generation | This is the parameter option that appears in JAVA 6 | |
| -XX:MaxGCPauseMillis | Maximum time (maximum pause time) for each young generation garbage collection | If this time cannot be met, the JVM automatically resizes the young generation to meet this value. | |
| -XX:+UseAdaptiveSizePolicy | Automatically selects the young zone size and the corresponding Survivor zone ratio | When this option is set, the parallel collector automatically selects the size of the young generation region and the corresponding Survivor region ratio to achieve the minimum corresponding time or collection frequency specified by the target system. This value is recommended to keep the parallel collector open when using it. | |
| -XX:GCTimeRatio | Set the garbage collection time as a percentage of program run time | Formula for 1 / (1 + n) | |
| -XX:+ScavengeBeforeFullGC | YGC is called before Full GC | true | Do young generation GC prior to a full GC. |
1.3 CMS Parameters
| -XX:+UseConcMarkSweepGC | Use CMS memory collection | After this was configured in the test, the -xx :NewRatio=4 configuration failed for unknown reasons. Therefore, it is best to set the size of the young generation with -xmn. | |
|---|---|---|---|
| -XX:+AggressiveHeap | Attempts to optimize large memory usage for a long time using a large amount of physical memory, can check the computing resources (memory, number of processors) required at least 256MB of memory with a large amount of CPU/memory, (as shown in 1.4.1 on 4CPU machines) | ||
| -XX:CMSFullGCsBeforeCompaction | How many times after memory compression | Because the concurrent collector does not compress or defragment the memory space, it can become “fragmented” after running for a while, making it less efficient. This value sets the number of GC runs after the memory space is compressed and collated. | |
| -XX:+CMSParallelRemarkEnabled | Drop mark pause | ||
| -XX+UseCMSCompactAtFullCollection | Compression of the tenured generation during FULL GC | CMS does not move memory, so it is very easy to fragment and run out of memory, so memory compression is enabled at this point. Adding this parameter is a good habit. Performance may be affected, but fragmentation can be eliminated | |
| -XX:+UseCMSInitiatingOccupancyOnly | Start CMS collection using manual definition initialization definitions | Disable HostSpot from triggering the CMS GC | |
| -XX:CMSInitiatingOccupancyFraction=70 | Start CMS collection after using 70% of CMS as garbage collection | 92 | To ensure that promotion failed(described below) errors do not occur, the value needs to be set according to the following formula **The formula CMSInitiatingOccupancyFraction** |
| -XX:CMSInitiatingPermOccupancyFraction | Set Perm Gen to use when triggering at what rate | 92 | |
| -XX:+CMSIncrementalMode | Set to incremental mode | Used for single CPU | |
| -XX:+CMSClassUnloadingEnabled |
1.4 Auxiliary Information
| -XX:+PrintGC | [GC 121376K->10414K, 0.0650971 SECs] [Full GC 121376K->10414K, 0.0650971 secs] | ||
|---|---|---|---|
| -XX:+PrintGCDetails | [GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] [GC [DefNew: 8614K) 8614 k – > 8614 k (9088 k), 0.0000665 secs] [Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs] | ||
| -XX:+PrintGCTimeStamps | |||
| -XX:+PrintGC:PrintGCTimeStamps | 11.851: [GC 98328K->93620K(130112K), 0.0082960 secs] | ||
| -XX:+PrintGCApplicationStoppedTime | Prints the time the program is paused during garbage collection. Can be mixed with the above | Total time for which Application Threads were Stopped: 0.0468229 seconds | |
| -XX:+PrintGCApplicationConcurrentTime | Prints the uninterrupted execution time of the program before each garbage collection. Can be mixed with the above | Application time: 0.5291524 seconds | |
| -XX:+PrintHeapAtGC | Prints detailed stack information before and after GC | ||
| -Xloggc:filename | Record relevant log information in a file for analysis. Use with the above ones | ||
| -XX:+PrintClassHistogram | garbage collects before printing the histogram. | ||
| -XX:+PrintTLAB | View TLAB space usage | ||
| XX:+PrintTenuringDistribution | Check the threshold for new life cycles after each Minor GC | Desired Survivor size 1048576 bytes, new Threshold 7 (Max 15) New threshold 7 that is, the threshold for the new survival period is 7. |
2.GC performance considerations
There are two indicators for GC performance: throughput (working time does not count the total time of GC) and pause (app cannot respond to the display when GC occurs).
2.1 the Total Heap
By default, the VM increases/decreases the heap size to maintain the ratio of free space to the total VM, which is specified by MinHeapFreeRatio and MaxHeapFreeRatio.
In general, server-side apps have the following rules:
- Allocate as much memory as possible to the VM;
- Set Xms and Xmx to the same value. If the vm starts with a small amount of memory and many objects need to be initialized, the vm must repeatedly increase memory.
- As the number of processor cores increases, so does memory.
2.2 The Young Generation
Another factor that affects the smooth running of an app is the size of the young generation. The larger the young generation is, the smaller the minor collection is. But in the case of fixed heap size, larger young generation means smaller Tenured generation, That means more major collections (major collections lead to minor collections).
NewRatio reflects the size ratio of young to Tenured generation. NewSize and MaxNewSize reflect the lower limit and upper limit of the size of young Generation. If the two values are set to the same, the size of young Generation is fixed (same as that of Xms and Xmx). SurvivorRatio can also optimize the size of survivor if desired, although this does not have a significant impact on performance. SurvivorRatio is the Eden to survior size ratio.
In general, server-side apps have the following rules:
- Determine the maximum heap size that can be allocated to the VM, and then set the optimal young generation size.
- If the heap size is fixed, increasing the size of young Generation means reducing the size of Tenured Generation. Make the Tenured Generation large enough to accommodate all live data at any given time (leaving 10%-20% free).
Rule of thumb
3.1 Young generation size selection
- Response time first applications: Set as large as possible until approaching the minimum response time limit of the system (selected based on the actual situation). In this case, the frequency of young generation collection is the smallest. At the same time, reduce the number of objects that reach the aged generation.
- Throughput first applications: as large as possible, possibly up to Gbit. Since there is no response time requirement, garbage collection can be done in parallel and is generally suitable for applications with more than 8 cpus.
- Avoid setting it too small. If the new generation is set too small, it will result in: 1.YGC is more frequent; 2. YGC may directly enter the old generation.
3.2 Aging generation size selection
Response time first applications: Older generations use concurrent collectors, so their size needs to be carefully set, generally taking into account parameters such as concurrent session rate and session duration. If the heap is set too small, it can cause memory fragmentation, high recycle frequency, and application pauses instead of traditional token cleanup. If the heap is large, it takes longer to collect. For optimal scenarios, the following data are generally required: concurrent garbage collection information, number of concurrent collections in persistent generation, traditional GC information, and the proportion of time spent collecting in young and old generation.
- Throughput-first applications: Typically throughput-first applications have a large young generation and a small old generation. The reason for this is that it is possible to recycle most of the short-term objects and reduce the medium-term objects, while the old generation is used to store the long-term living objects.
- Fragmentation problems caused by small heaps: Because the concurrent collector of the older generation uses a mark-clean algorithm, the heap is not compressed. When the collector collects, it merges adjacent Spaces so that they can be allocated to larger objects. However, when heap space is low, “fragmentation” can occur after running for a while, and if the concurrent collector cannot find enough space, the concurrent collector will stop and recycle using the traditional mark-clean method. If there is a “fragments”, may need to have the following configuration: – XX: + UseCMSCompactAtFullCollection. When using a concurrent collector, turn on compression for the aged generation. – XX: CMSFullGCsBeforeCompaction = 0: the above configuration under the condition of open, set how much time after Full GC, here to compress old generation.
- With 64-bit operating systems, the 64-bit JDK under Linux is slower than the 32-bit JDK, but it eats more memory and has more throughput.
- XMX is set to the same size as XMS and MaxPermSize is set to the same size as MinPermSize to reduce the stress of scaling the heap size.
- The advantage of using CMS is to use as few new generation as possible, the experience value is 128m-256m, and then use CMS for parallel collection of old generation, which can ensure the throughput efficiency of the system with low delay. In fact, the CMS collection pause time is very short, 2G of memory, about 20-80ms of application pause time
- When the system stops, it may be a GC problem or a program problem, use jMap and jStack to check, or killall-3 Java, and then check the Java console log, you can see many problems.
- If the cache is used, the aged generation should be larger and the length of the cache HashMap should not be unlimited. It is recommended to use the LRU algorithm Map as the cache, and the maximum length of the LRUMap should also be set according to the actual situation.
- When concurrent recycling is used, the young generation is smaller, and the old generation is larger, because the old generation is used concurrently. Even if it takes a long time, it will not affect other programs to continue to run, and the website will not stop.
- There is no fixed formula for setting JVM parameters (especially — Xmx — Xms — XMN-XX :SurvivorRatio -XX:MaxTenuringThreshold and other parameters, which need to be measured according to the actual DATA YGC times in PV old zone. In order to avoid promotion faild, the XMN setting may be too small, which also means the number of YGC will increase, and the ability to handle concurrent access will decrease. Each parameter adjustment requires detailed performance testing to find the best configuration for a particular application.
1.JVM series three :JVM parameter Settings, analysis