JVM Lesson 11: Summary of JVM Common Parameters

foreword

In the production system, Serial is almost useless;
now, the ZGC of HotSpot is not mature, and the best GC to use at present is G1.
JDK8 starts to support G1

Conservative companies may use JDK7. At this time, the response time is actually prioritized, that is, PS + PO is used;
once CMS is SerialOld, it will STW for a long time, so there is no need to use it, and it will bring a lot of trouble (CMS Helped G1 and ZGC to step on a lot of pits)
If you use JDK8, then it is recommended to use G1

Problems with CMS

Memory Fragmentation

-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction defaults to 0, which refers to how many times FGC is used to compress

Floating Garbage

Concurrent Mode Failure
: if the concurrent collector is unable to finish reclaiming the unreachable objects before the tenured generation fills up, or if an allocation cannot be satisfied with the available free space blocks in the tenured generation, then the application is paused and the collection is completed with all the applicationthreads stopped
solution: lower the threshold that triggers the CMS
PromotionFailed The
solution is similar to keep enough space in the old age
–XX:CMSInitiatingOccupancyFraction 92% This value can be lowered to allow the CMS to keep enough space in the old age

CMS log format

Execute the command: java -Xms20M -Xmx20M -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC com.mashibing.jvm.gc.T15_FullGC_Problem01

The result is as follows:
[GC (Allocation Failure) [ParNew: 6144K->640K(6144K), 0.0265885 secs] 6585K->2770K(19840K), 0.0268035 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]

ParNew: Young generation collector
6144->640: Comparison before and after collection
(6144): Entire young generation capacity
6585 -> 2770: Entire heap situation
(19840): Entire heap size

[GC (CMS Initial Mark) [1 CMS-initial-mark: 8511K(13696K)] 9866K(19840K), 0.0040321 secs] 
[Times: user=0.01 sys=0.00, real=0.00 secs] 
	//8511 (13696) : 老年代使用(最大)
	//9866 (19840) : 整个堆使用(最大)
[CMS-concurrent-mark-start]
[CMS-concurrent-mark: 0.018/0.018 secs] [Times: user=0.01 sys=0.00, real=0.02 secs] 
	//这里的时间意义不大,因为是并发执行
[CMS-concurrent-preclean-start]
[CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
	//标记Card为Dirty,也称为Card Marking
[GC (CMS Final Remark) [YG occupancy: 1597 K (6144 K)]
[Rescan (parallel) , 0.0008396 secs][weak refs processing, 0.0000138 secs][class unloading, 0.0005404 secs]
[scrub symbol table, 0.0006169 secs][scrub string table, 0.0004903 secs]
[1 CMS-remark: 8511K(13696K)] 10108K(19840K), 0.0039567 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
	//STW阶段,YG occupancy:年轻代占用及容量
	//[Rescan (parallel):STW下的存活对象标记
	//weak refs processing: 弱引用处理
	//class unloading: 卸载用不到的class
	//scrub symbol(string) table: 
		//cleaning up symbol and string tables which hold class-level metadata and 
		//internalized string respectively
	//CMS-remark: 8511K(13696K): 阶段过后的老年代占用及容量
	//10108K(19840K): 阶段过后的堆占用及容量

[CMS-concurrent-sweep-start]
[CMS-concurrent-sweep: 0.005/0.005 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
	//标记已经完成,进行并发清理
[CMS-concurrent-reset-start]
[CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
	//重置内部结构,为下次GC做准备

G1 log format

Garbage First Garbage Collector Tuning

If you produce jdk 1.8, you can use G1. It is recommended that you use it.

G1 is to logically divide the heap memory into many small blocks (Region)
Before G1, PS, CMS, etc., will set a Xmn young generation size;
but G1 does not recommend specifying the young generation size, because G1 will automatically adjust it (according to YGC time and set pause time)

Several recycling stages of G1:

  • YGC(STW)
  • MixedGC, much like the four phases of a CMS
  • FGC(SerialOld)
    The tuning goal of G1 is to avoid FGC as much as possible

Excuting an order:java -Xms20M -Xmx20M -XX:+PrintGCDetails -XX:+UseG1GC com.mashibing.jvm.gc.T15_FullGC_Problem01

[GC pause (G1 Evacuation Pause) (young) (initial-mark), 0.0015790 secs]
//young -> 年轻代 , Evacuation-> 复制存活对象 
//initial-mark 混合回收的阶段,这里是YGC混合老年代回收
   [Parallel Time: 1.5 ms, GC Workers: 1] //一个GC线程
      [GC Worker Start (ms):  92635.7]
      [Ext Root Scanning (ms):  1.1]
      [Update RS (ms):  0.0]
         [Processed Buffers:  1]
      [Scan RS (ms):  0.0]
      [Code Root Scanning (ms):  0.0]
      [Object Copy (ms):  0.1]
      [Termination (ms):  0.0]
         [Termination Attempts:  1]
      [GC Worker Other (ms):  0.0]
      [GC Worker Total (ms):  1.2]
      [GC Worker End (ms):  92636.9]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.0 ms]
   [Other: 0.1 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 0.0 ms]
      [Ref Enq: 0.0 ms]
      [Redirty Cards: 0.0 ms]
      [Humongous Register: 0.0 ms]
      [Humongous Reclaim: 0.0 ms]
      [Free CSet: 0.0 ms]
   [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 18.8M(20.0M)->18.8M(20.0M)]
 [Times: user=0.00 sys=0.00, real=0.00 secs] 
//以下是混合回收其他阶段
[GC concurrent-root-region-scan-start]
[GC concurrent-root-region-scan-end, 0.0000078 secs]
[GC concurrent-mark-start]
//无法evacuation,进行FGC
[Full GC (Allocation Failure)  18M->18M(20M), 0.0719656 secs]
   [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 18.8M(20.0M)->18.8M(20.0M)], [Metaspace: 38
76K->3876K(1056768K)] [Times: user=0.07 sys=0.00, real=0.07 secs]

GC common parameters

GC general parameters

  • -Xmn -Xms -Xmx -Xss
    Young generation min heap max stack space

  • -XX:+PrintFlagsInitial
    Default value of each parameter of JVM

  • -XX:+UseTLAB
    Use TLAB, open by default, it is recommended not to move

  • -XX:+PrintTLAB
    prints the usage of TLAB

  • -XX:TLABSize
    set TLAB size, it is recommended not to move

  • -XX:+DisableExplictGC
    makes System.gc() useless. Generally, the
    System.gc() method is turned on. The program recommends the JVM to perform FGC.

  • -XX:+PrintGC
    print GC log

  • -XX:+PrintGCDetails
    prints the GC details log

  • -XX:+PrintHeapAtGC
    Print stack situation during GC

  • -XX:+PrintGCTimeStamps
    Print system time during GC

  • -XX:+PrintGCApplicationConcurrentTime (low)
    print application time

  • -XX:+PrintGCApplicationStoppedTime (low)
    Print pause time

  • -XX:+PrintReferenceGC (low importance)
    records how many references of different reference types are reclaimed

  • -verbose:class
    class loading detailed process

  • -XX:+PrintVMOptions
    print JVM runtime parameters

  • -XX:+PrintFlagsFinal
    The final value of each parameter of the JVM is
    equivalent to the JVM parameter dictionary table
    must use

  • -Xloggc:opt/log/gc.log
    record GC log

  • -XX:MaxTenuringThreshold
    promotion age, the maximum value is 15 (CMS default 6, others default 15)

  • Lock spin times-XX:PreBlockSpin; Hotspot code detection parameters-XX:CompileThreshold; Escape analysis scalar replacement...
    These are not recommended to set

Parallel common parameters

  • -XX:SurvivorRatio
    Eden : S0 : S1 The default ratio is 8 : 1 : 1

  • -XX: How big is the PreTenureSizeThreshold
    large object, it will be directly allocated to the old area

  • -XX:MaxTenuringThreshold promotion age

  • -XX:+ParallelGCThreads
    The number of parallel collector threads, also applicable to CMS, generally set to the same as the number of CPU cores

  • -XX:+UseAdaptiveSizePolicy
    automatically selects the size ratio of each area

CMS common parameters

  • -XX:+UseConcMarkSweepGC

  • -XX: ParallelCMSThreads
    The number of CMS threads, CMS is only the GC of the Old area, so some resources should be reserved for others

  • -XX:CMSInitiatingOccupancyFraction
    uses what percentage of the old age to start CMS collection, the default is 68% (approximate value),
    if SerialOld freezes frequently, it should be reduced, (CMS recycling is more frequent)

  • -XX:+UseCMSCompactAtFullCollection
    compresses during FGC (CMS does not compress by default, just Sweep; GC time increases during compression)
    Resolving FGC Fragmentation

  • -XX:CMSFullGCsBeforeCompaction
    how many times to compress after FGC
    Resolving FGC Fragmentation

  • -XX:+CMSClassUnloadingEnabled
    Class in the recycling method area

  • -XX: CMSInitiatingPermOccupancyFraction
    when the percentage of Perm recycling is reached (when JDK<=1.7, the method area is implemented by the permanent generation)

  • GCTimeRatio
    sets the percentage of GC time occupied by the running time of the program, which is a suggestion

  • -XX:MaxGCPauseMillis
    pause time, is a recommended time, GC will try to achieve this time by various means, such as reducing the young generation

G1 common parameters

  • -XX:+UseG1GC

  • -XX:MaxGCPauseMillis
    pause time, the recommended value, G1 will try to adjust the number of blocks in the Young area to achieve this value

  • -XX:GCPauseIntervalMillis
    ? GC pause interval

  • -XX:+G1HeapRegionSize
    partition size, it is recommended to gradually increase the value, 1 2 4 8 16 32.
    As the size increases, the garbage will live longer, the GC interval will be longer, but the time of each GC will be longer
    . ZGC has improved (dynamic block size)

  • G1NewSizePercent The
    minimum proportion of the new generation, the default is 5%

  • G1MaxNewSizePercent The
    maximum proportion of the new generation, the default is 60%
    G1 will dynamically adjust the size of the new generation

  • GCTimeRatio The
    recommended ratio of GC time, G1 will adjust the heap space according to this value

  • ConcGCThreads
    number of threads

  • InitiatingHeapOccupancyPercent
    startup G1 heap space occupation ratio

Fiber (coroutine)

Find out for yourself
insert image description here

Guess you like

Origin blog.csdn.net/upset_poor/article/details/123167388