Java performance-garbage collection/Garbage Collection

As the hardware continues to grow, Java Heap is growing, and reasonable garbage collection tuning becomes increasingly important. Here are some best practices:

Attention:

1. IBM AIX Java is not covered below. It also does not introduce the principle, just the recommendations and initial configuration/best practices, and how to iteratively optimize
2. Need to understand the Java Virtual machine specification > Run-time Data areas and Memory Management whitepaper

• Configure the appropriate heap memory size
  • By configuring the-XMS-XMX setting, the initial and maximum values are indicated respectively
  • Can be 4G, 8G, 12G, 16G, even 24G, etc.
  • About young and old default 1:2 ratio (-xx:newratio), not very recommended to start the adjustment, followed by GC check

• Garbage Collection Optimization Recommendations
  • • Configure-XX:+DISABLEEXPLICITGC
      • Many of the code will have a System.GC () call to trigger garbage collection, which can be unnecessarily burdensome; the configuration ignores the API call.
    • Select GC Policy
      • Java 7 Recommended Default-multithreaded parallel garbage collection regardless of yong/old, the number of threads is the number of CPUs
      • Java 6-Default young multithreading and running, old single thread. We recommend configuring the old multithreaded parallel configuration-XX:+USEPARALLELOLDGC
      • The number of threads is configured by -xx:parallelgcthreads , the recommended value is the number of CPUs divided by the number of JVMs
    • Other GC policies
      • Java 6 -XX:+USECONCMARKSWEEPGC, is not recommended because Java 7 is obsolete; There is a BUG, and at the same time there is a phase that will pause the JVM, and for a very long time-6G heap may take dozens of seconds
      • G1 since Java 7-no GC bugs are fatal.
        
        
• Monitor GC status
  • Print GC verbose logs by configuring-xx:+printgcdatestamps-xx:+printgcdetails-xloggc:<path>/gc.log
  • Analyze GC Frequency
  • Analyze pre-and post-GC memory conditions
  • Analyze GC user, sys, real time-consuming
  • For example-The following is a clear reflection of operating system bugs, in the case of parallel GC, approximately should be the number of user/gc threads = Real
    

    [GC [psyounggen:6144000k->423839k (7168000K)] 6455356k->735195k (15360000K),182.4565520secs] [times:user=1.71sys=1454.44, real=182.43secs]
    --YoungGC, a total of 7168000K size, used 6144000K before collection, followed by 423839K, total time 182.4565520 sec[GC [psyounggen:629652k->413103K (7168000K)] 941009k->724459k (15360000K),116.7165380secs] [times:user=1.25sys=932.20, real=116.70secs]
    --YoungGC,user=1.25 (GC CPU time) sys=932.20 (OS time), real=116.70 secs (total time consuming) /c6>[Full GC [psyounggen:367256k->0k (7495680K)] [paroldgen:429715k->699671k (8192000K)] 796972k->699671k (15687680K) [pspermgen:126393k- >126390k (2097152K)],558.1420070secs] [times:user=2.77sys=4458.28, real=558.06secs
    --full GC 

Java performance-garbage collection/Garbage Collection