Java Virtual Machine - JVM various parameter configurations in detail


usr/local/jdk/bin/java -Dresin.home=/usr/local/resin -server -Xms1800M -Xmx1800M -Xmn300M -Xss512K -XX:PermSize=300M -XX:MaxPermSize=300M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:GCTimeRatio=19 -Xnoclassgc -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:-CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log
  1. Heap Size Setting
    the maximum heap size in the JVM has three limitations: the data model (32-bit or 64-bit) limit of the relevant operating system; the system's available virtual memory limit; the system's available physical memory limit. Under the 32-bit system, it is generally limited to 1.5G~2G; 64 means that the operating system has no limit on the memory. I tested under Windows Server 2003 system, 3.5G physical memory, JDK5.0, the maximum can be set to 1478m.
    Typical setup:
    • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
      -
      Xmx3550m : Set the maximum available memory of the JVM to 3550M.
      -Xms3550m
      : Set the JVM to promote memory to 3550m. This value can be set the same as -Xmx to avoid reallocation of memory by the JVM after each garbage collection is complete.
      -Xmn2g
      : Set the young generation size to 2G. Whole heap size = young generation size + old generation size + persistent generation size . The persistent generation is generally fixed at 64m, so after increasing the young generation, the size of the old generation will be reduced. This value has a great impact on system performance, and Sun officially recommends setting it to 3/8 of the entire heap.
      -Xss128k
      : Set the stack size per thread. After JDK5.0, the stack size of each thread is 1M, and the previous stack size of each thread is 256K. Adjust the memory size required by the threads of the application. In the same physical memory, reducing this value can generate more threads. However, the operating system still has a limit on the number of threads in a process, which cannot be generated indefinitely, and the experience value is around 3000~5000.
    • java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
      -XX:NewRatio=4
      : Set the young generation (including Eden and two Survivor areas) Ratio to old generation (excluding persistent generation). If set to 4, the ratio of the young generation to the old generation is 1:4, and the young generation accounts for 1/5 of the entire stack.
      -XX:SurvivorRatio=4
      : Set the size ratio of the Eden area to the Survivor area in the young generation. If set to 4, the ratio of two Survivor areas to one Eden area is 2:4, and one Survivor area occupies 1/6 of the entire young generation
      -XX:MaxPermSize=16m : Set the persistent generation size to 16m.
      -XX:MaxTenuringThreshold=0 : Set the maximum age of garbage. If it is set to 0, the young generation objects directly enter the old generation without passing through the Survivor area . For applications with a large number of old generations, the efficiency can be improved. If this value is set to a larger value, the young generation object will be replicated multiple times in the Survivor area, which can increase the survival time of the object in the young generation and increase the generalization that it will be recycled in the young generation.
  2. Collector selection
    JVM gives three choices: serial collector, parallel collector, concurrent collector , but serial collector is only suitable for small data volume, so the choice here is mainly for parallel collector and concurrent collector . By default, JDK5.0 used to use serial collectors. If you want to use other collectors, you need to add corresponding parameters at startup. After JDK5.0, the JVM will judge according to the current system configuration .
    1. Parallel collectors with throughput priority
      As mentioned above, parallel collectors mainly aim to achieve a certain throughput, and are suitable for scientific technology and background processing.
      Typical configuration :
      • java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
        -XX:+UseParallelGC
        : Select the garbage collector as the parallel collector. This configuration is only valid 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:ParallelGCThreads=20
        : Configure the number of parallel collector threads, that is, how many threads to perform garbage collection together at the same time. 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 as parallel collection. JDK6.0 supports parallel collection of the old generation.
      • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100
        -XX:MaxGCPauseMillis=100
        : Set the maximum time for each young generation garbage collection. If this time cannot be met, the JVM will automatically adjust the young Generation size to satisfy this value.
      • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy
        -XX:+UseAdaptiveSizePolicy
        : After setting this option, the parallel collector will automatically select the young generation area size and the corresponding Survivor Area ratio to achieve the minimum corresponding time or collection frequency specified by the target system, etc. This value is recommended to be turned on when the parallel collector is used.
    2. Concurrent collectors that prioritize response time
      As mentioned above, concurrent collectors are mainly to ensure the response time of the system and reduce the pause time during garbage collection. Applicable to application servers, telecommunication fields, etc.
      Typical configuration :
      • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
        -XX:+UseConcMarkSweepGC : Set the old generation for concurrent collection. After configuring this in the test, the configuration of -XX:NewRatio=4 is invalid for unknown reasons. Therefore, the young generation size is best set with -Xmn at this time.
        -XX:+UseParNewGC : Set the young generation for parallel collection. Can be used concurrently with CMS collection. Above JDK5.0, the JVM will set itself according to the system configuration, so there is no need to set this value.
      • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
        -XX:CMSFullGCsBeforeCompaction : Since the concurrent collector does not compress and organize the memory space, it will generate "" Fragmentation", which reduces operational efficiency. This value sets how many times to compress and organize the memory space after running GC.
        -XX:+UseCMSCompactAtFullCollection : Turn on compression for the old generation. May affect performance, but can eliminate fragmentation
  3. Auxiliary information
    JVM provides a large number of command line parameters, printing information, for debugging. There are mainly the following:
    • -XX:+PrintGC
      output format : [GC 118250K->113543K(130112K), 0.0094143 secs]

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

    • -XX:+PrintGCDetails
      output format : [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 the uninterrupted execution time of the program before each garbage collection.
      The output form can be mixed with the above : Application time: 0.5291524 seconds
    • -XX:+PrintGCApplicationStoppedTime : Print the time the program was paused during garbage collection.
      The output form can be mixed with the above : Total time for which application threads were stopped: 0.0468229 seconds
    • -XX:PrintHeapAtGC :打印GC前后的详细堆栈信息
      输出形式:
      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 : Used in conjunction with the above, log relevant log information to a file for analysis.
  4. Summary of common configurations
    1. heap settings
      • -Xms : initial heap size
      • -Xmx : maximum heap size
      • -XX:NewSize=n : Set the young generation size
      • -XX:NewRatio=n: Set the ratio of young generation to old generation. For example, it is 3, which means that the ratio of young generation to old generation is 1:3, and the young generation accounts for 1/4 of the sum 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 the Survivor area has two. For example: 3 means Eden: Survivor=3:2, a Survivor area occupies 1/5 of the entire young generation
      • -XX:MaxPermSize=n : Set persistent generation size
    2. Collector settings
      • -XX:+UseSerialGC : Set serial collector
      • -XX:+UseParallelGC : set parallel collector
      • -XX:+UseParalledlOldGC : Set the parallel old generation collector
      • -XX:+UseConcMarkSweepGC : Set concurrent collector
    3. Garbage Collection Statistics
      • -XX:+PrintGC
      • -XX:+PrintGCDetails
      • -XX:+PrintGCTimeStamps
      • -Xloggc:filename
    4. Parallel collector settings
      • -XX:ParallelGCThreads=n : Set the number of CPUs used by the parallel collector for collection. Number of parallel collection threads.
      • -XX:MaxGCPauseMillis=n : Set the maximum pause time for parallel collection
      • -XX:GCTimeRatio=n : Set the percentage of garbage collection time to program running time. The formula is 1/(1+n)
    5. Concurrent collector settings
      • -XX:+CMSIncrementalMode : Set to incremental mode. Suitable for single CPU situation.
      • -XX:ParallelGCThreads=n : Set the number of CPUs used when the young generation collection mode of the concurrent collector is parallel collection. Number of parallel collection threads.


4. Tuning summary

  1. Young Generation Size Selection
    • Response time priority applications : set as large as possible until it is close to the minimum response time limit of the system (selected according to the actual situation). In this case, the frequency of young generation collections is also minimal. At the same time, reduce the objects that reach the old generation.
    • Applications with throughput priority : 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 more than 8 CPUs.
  2. Old Generation Size Selection
    • Response time priority applications : The old generation uses concurrent collectors, so its size needs to be set carefully. Generally , some parameters such as concurrent session rate and session duration should be considered. If the heap setting is small, it can cause memory fragmentation, high collection frequency and application suspension and use the traditional mark-and-sweep method; if the heap is large, it will take a long time to collect. The optimal solution generally needs to be obtained by referring to the following data:
      • Concurrent garbage collection information
      • Persistent Generation Concurrent Collection Times
      • Legacy GC Information
      • Proportion of time spent on young and old collections
      Reducing the time spent in the young and old generation generally improves the efficiency of the application
    • Throughput-first applications : Generally, throughput-first applications have a large young generation and a small old generation. The reason is that most of the short-term objects can be recycled as much as possible, reducing the medium-term objects, and the old generation can store long-lived objects.
  3. Fragmentation problems caused by smaller heaps
    Because the old generation concurrent collector uses a mark-and-sweep algorithm, the heap is not compacted. When the collector recycles, it merges adjacent spaces so that they can be allocated to larger objects. However, when the heap space is small, "fragmentation" will occur after running for a period of time. If the concurrent collector cannot find enough space, the concurrent collector will stop, and then use the traditional mark and clear method for recycling. If "fragmentation" occurs, the following configuration may be required:
    • -XX:+UseCMSCompactAtFullCollection : When using the concurrent collector, enable compaction of the old generation.
    • -XX:CMSFullGCsBeforeCompaction=0 : When the above configuration is enabled, how many times of Full GC are set here to compress the old generation

  
jvm parameter configuration

a: -Xmx<n>                       

Specify the maximum heap size of the jvm, such as: -Xmx=2g


b: -Xms<n>                       

Specify the minimum heap size of jvm, such as: -Xms=2g, for high concurrent applications, it is recommended to be the same as -Xmx to prevent performance impact due to memory shrinkage/sudden increase.


c: -Xmn<n>                       

Specify the size of New Generation in jvm, such as: -Xmn256m. This parameter affects performance. If your program needs more temporary memory, it is recommended to set it to 512M. If it is used less, try to lower this value. Generally speaking, 128/256 is enough.


d: -XX:PermSize=<n>

Specify the minimum value of Perm Generation in jvm, such as: -XX:PermSize=32m. This parameter depends on your actual situation. You can use the jmap command to see how much is needed.


e: -XX:MaxPermSize=<n>           

Specify the maximum value of Perm Generation, such as: -XX:MaxPermSize=64m


f: -Xss<n>                       

Specify the thread size, such as: -Xss128k. Generally speaking, applications under the webx framework require 256K. If your program has massive recursive behavior, please consider setting it to 512K/1M. This requires comprehensive testing to know. Still, 256K is already huge. This parameter has a large impact on performance.


g: -XX:NewRatio=<n>

Specify the ratio of Old Generation heap size to New Generation in jvm. This parameter is invalid when CMS GC is used, such as: -XX:NewRatio=2


h: -XX:SurvivorRatio=<n>

Specify the heap size ratio between Eden Space and a Survivor Space in New Generation, -XX:SurvivorRatio=8, then when the total New Generation is 10m, the Eden Space is 8m


i: -XX: MinHeapFreeRatio = <n>

Specify the jvm heap to shrink when the usage rate is less than n, and invalid when Xmx==Xms, such as: -XX:MinHeapFreeRatio=30


j: -XX:MaxHeapFreeRatio=<n>

Specify the jvm heap to expand when the usage rate is greater than n, and it is invalid when Xmx==Xms, such as: -XX:MaxHeapFreeRatio=70


k: -XX:LargePageSizeInBytes=<n>

Specify the page size of the Java heap, such as: -XX:LargePageSizeInBytes=128m


2: garbage collector

a: -XX:+UseParallelGC

Specify to use parallel collector in New Generation, parallel collection, suspend app threads, start multiple garbage collection threads at the same time, cannot be used together with CMS gc. System tonnage takes priority, but there will be a long app pause, background system tasks This gc can be used


b: -XX:ParallelGCThreads=<n>

Specify the number of threads to start when parallel collection, the default is the number of physical processors,


c: -XX:+UseParallelOldGC

Specifies to use parallel collector in Old Generation


d: -XX:+UseParNewGC

Specifies to use parallel collector in New Generation, which is an upgraded version of UseParallelGC's gc, has better performance or advantages, and can be used together with CMS gc


e: -XX:+CMSParallelRemarkEnabled

In the case of using UseParNewGC, try to reduce the time of mark


f: -XX:+UseConcMarkSweepGC

Specify to use concurrent cmark sweep gc in Old Generation, gc thread and app thread in parallel (pause app thread during init-mark and remark). The app pause time is short, suitable for systems with strong interaction, such as web server


g: -XX:+UseCMSCompactAtFullCollection

In the case of using concurrent gc, prevent memory fragmention, organize live objects, and reduce memory fragmentation


h: -XX:CMSInitiatingOccupancyFraction=<n>

Instructs to start the concurrent collector after using n% of the old generation, the default value is 68, such as: -XX:CMSInitiatingOccupancyFraction=70

There is a bug, which appeared on jvm of lower version (1.5.09 and early), http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486089


i: -XX:+UseCMSInitiatingOccupancyOnly

Instructs the concurrent collector to start collecting only after the old generation has used the initialized scale


3:others

a: -XX:MaxTenuringThreshold=<n>

Specifies that an object will be transferred to the old generation area after n times of young gc. The default value is 15 under java6 of linux64. This parameter is invalid for throughput collector, such as: -XX:MaxTenuringThreshold=31


b: -XX:+DisableExplicitGC

Forbid full gc in java program, such as System.gc() call. It is better to add it to prevent the program from being misused in the code. impact on performance.


c: -XX:+UseFastAccessorMethods

get,set methods converted to native code


d: -XX:+PrintGCDetails

The situation that should be garbage collected is as follows:

[GC 15610.466: [ParNew: 229689K->20221K(235968K), 0.0194460 secs] 1159829K->953935K(2070976K), 0.0196420 secs]


e: -XX:+PrintGCTimeStamps

The timing of garbage collection, such as:

[Times: user=0.09 sys=0.00, real=0.02 secs]


f: -XX:+PrintGCApplicationStoppedTime

When the garbage collection is called, the system pause time, such as:

Total time for which application threads were stopped: 0.0225920 seconds


4: a web server product sample and process

JAVA_OPTS=" -server -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 "


In the beginning, we used UseParallelGC and UseParallelOldGC, the heap turned on 3G, and the NewRatio was set to 1. In this configuration, the frequency of young gc is about 12.3 times, and the average cost is about 80ms each time. The frequency of full gc is extremely low. It takes about 1s for each time. Judging from the system time consumed by all gcs, the system utilization rate is still high, but whether it is young gc or old gc, the time of applicaton thread pause is relatively long, which is not suitable for web applications. , but this will lengthen the full gc time.


Later, we used CMS gc(-XX:+UseConcMarkSweepGC), the total heap at that time was still 3g, and after the new generation was 1.5g, the observation was not ideal, so we changed the jvm heap to 2g and set -Xmn1g for the new generation, in this case young The frequency of gc occurrence becomes, 7, 8 times, the average time is about 40~50 milliseconds each time, CMS gc rarely occurs, each time in init-mark and remark (two steps stop all app thread) a total of 80 ~90ms or so.


Here we have adjusted the New Generation to 1400m, a total of 2g of jvm heap, and the average time spent on each ygc is about 60~70ms. The sum of the init-mark and remark of CMS gc is about 50ms on average. Here we realize the wrong direction. , or the role of CMS, so modified


Finally, we adjust the New Generation to 256m, the young gc occurs once every 2,3 seconds, the average pause time is about 25ms, and the average sum of the init-mark and remark of the CMS gc is about 50ms, which makes the system relatively smooth, after the stress test , the system performance is relatively high under this configuration


When using CMS gc, he has two ways to trigger gc: gc estimation trigger and heap occupancy trigger. In our 1.5.0.09 environment, there was a time when the old area heap occupied about 30%, she would frequently gc, and the personal feeling system estimated This method of triggering is unreliable, and it is safer to use the heap to use the ratio trigger.


These data are all from the 64-bit test machine. The data in the process are all found by me in the jboss log. I didn't write it down at that time. There may be a little deviation, but it will not be very large. The basic process is like this.


5: Summary

As an application with high interactive requirements, web server should use Parallel+CMS, UseParNewGC is the default on jdk6-server, new generation gc, the new generation should not be too large, so that each pause will be shorter. CMS mark- The sweep generation can be larger and can be controlled according to the actual situation of pause time

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324813245&siteId=291194637