JVM Performance Tuning Getting Started Guide

Source: Internet
Author: User

Objective

After getting started with the JVM garbage collection mechanism, you can then learn the performance tuning. There are two main parts of the content:

    • The use of JDK tools.
    • Tuning strategy.
Weapon Spectrum JPS

List the running virtual machine processes, using the following:

JPS [-option] [HostID]
Options function
Q Output only Lvmid, omit the name of the main class
M Output the parameters of Main method
L Output the full package name, apply the main class name, the full path name of the jar
V Output JVM Parameters
Jstat

To monitor the virtual machine health status information, how to use:

Jstat-<option> <pid> [Interval[s|ms]
Options function
Gc The amount of time that the GC operation accumulates, the total number of times that the GC has been performed, and the amount of space that is currently available for each heap area.
Gccapactiy Outputs the minimum space limit (MS)/Maximum space limit (MX) for each heap area, the current size, and the number of times the GC is executed on top of each zone. (The current used space is not output and the GC execution time).
Gccause Outputs the information provided by-gcutil and why the GC was last executed and the reason for the GC that is currently executing.
Gcnew The GC performance data for the output generation space.
Gcnewcapacity Statistics on the size of the output Cenozoic space.
Gcold Output GC performance data for the old age space.
Gcoldcapacity Output statistics of the size of the old age space.
Gcpermcapacity Statistics that output the size of the persistent space.
Gcutil Outputs the usage ratio for each heap area, as well as the total number of GC executions and events spent by GC operations.

Like what:

JSTAT-GC 28389 1s

Output JVM Runtime information every 1 seconds:

s0c    s1c    s0u    s1u      EC       EU        OC         OU       PC     PU    ygc    ygct FGC FGCT     GCT   52416.0 52416.0 4744.9  0.0   419456.0 28180.6  2621440.0 439372.6 131072.0 33564.8 160472 1760.603      2.731 1763.334
column Description jstat Parameters
s0c The size of the Survivor0 space. Unit KB. -gc-gccapacity-gcnew-gcnewcapacity
S1c The size of the Survivor1 space. Unit KB. -gc-gccapacity-gcnew-gcnewcapacity
s0u Survivor0 the size of the space already used. Unit KB. -gc-gcnew
s1u Survivor1 the size of the space already used. Unit KB. -gc-gcnew
EC The size of the Eden space. Unit KB. -gc-gccapacity-gcnew-gcnewcapacity
EU The size of Eden used space. Unit KB. -gc-gcnew
Oc The size of the old age space. Unit KB. -gc-gccapacity-gcold-gcoldcapacity
OU The old age has used the size of space. Unit KB. -gc-gcold
Pc The size of the persistent generation space. Unit KB. -gc-gccapacity-gcold-gcoldcapacity-gcpermcapacity
Pu The size of the space that is used for persistent generations. Unit KB. -gc-gcold
Ygc The number of times the generation of space GC time occurred. -gc-gccapacity-gcnew-gcnewcapacity-gcold-gcoldcapacity-gcpermcapacity-gcutil-gccause
Ygct The time taken by the new generation of GC processing. -gc-gcnew-gcutil-gccause
FGC The number of times the full GC occurred. -gc-gccapacity-gcnew-gcnewcapacity-gcold-gcoldcapacity-gcpermcapacity-gcutil-gccause
Fgct The time spent by the full GC operation. -gc-gcold-gcoldcapacity-gcpermcapacity-gcutil-gccause
GCT Total time spent by GC operations. -gc-gcold-gcoldcapacity-gcpermcapacity-gcutil-gccause
Ngcmn Cenozoic minimum space capacity, in kilobytes. -gccapacity-gcnewcapacity
Ngcmx Maximum space capacity in the Cenozoic, in kilobytes. -gccapacity-gcnewcapacity
Ngc Current space capacity in the new generation, in kilobytes. -gccapacity-gcnewcapacity
Ogcmn The minimum space capacity in the old age, in kilobytes. -gccapacity-gcoldcapacity
Ogcmx The maximum space capacity in the old age, in kilobytes. -gccapacity-gcoldcapacity
OGC The current space capacity system in the old age, in kilobytes. -gccapacity-gcoldcapacity
Pgcmn The minimum space capacity of a persistent generation, in kilobytes. -gccapacity-gcpermcapacity
Pgcmx The maximum space capacity, in kilobytes, for a persistent generation. -gccapacity-gcpermcapacity
Pgc The current space capacity, in kilobytes, for the persistent generation. -gccapacity-gcpermcapacity
Pc The current space size, in kilobytes, of the persistent generation. -gccapacity-gcpermcapacity
Pu The current space size, in kilobytes, of the persistent generation. -gc-gcold
lgcc The reason for the last GC to occur. -gccause
Gcc The reason for the current GC to occur. -gccause
Tt The threshold of aging. The number of empty lives in the Cenozoic before being moved to the old age. -gcnew
Mtt Maximum age threshold. The number of empty lives in the Cenozoic before being moved to the old age. -gcnew
Dss The amount of space required for the survivor area, in kilobytes. -gcnew
Jmap

Heap storage snapshots, using:

Jmap [-option] <pid>
Options function
Dump A heap of storage snapshots in the format:-dump:[live,]format=b, file=<filename>,live indicates whether to dump only the surviving objects.
Heap Displays Java heap details, such as the use of that collector, parameter configuration, generational status, and so on.
Histo Displays the object statistics in the heap, including the class, number of instances, and total capacity.
Jstack

Generates a thread snapshot of the current moment of the virtual machine, helping to locate the cause of the thread's long pause, using:

Jstack <pid>

Monitor

Monitor is the primary means of using Java to achieve mutual exclusion and collaboration between threads, which can be seen as an object or class lock. Every object has, and only one monitor. The following diagram depicts the relationship between the thread and monitor, and the state transition diagram of the thread:

Entry Zone (ENTRT Set): Indicates that the thread acquires the lock of the object through synchronized requirements, but does not get it.

Owner (the owner): indicates that the thread successfully competed to the object lock.

Wait Set: Indicates that the thread passes the object's Wait method, frees the object's lock, and waits in the wait area to be awakened.

Thread state

    • NEW, not started. does not appear in dump.
    • RUNNABLE, executed within the virtual machine.
    • BLOCKED, wait for the monitor lock.
    • Wating, waits indefinitely for another thread to perform a specific operation.
    • Timed_wating, a time-bound wait for a specific operation on another thread.
    • TERMINATED, has exited.

As an example:

package Com.jiuyan.mountain.test;import java.util.concurrent.timeunit;/*** Hello world!* */public class App {public static void main (string[] args) throws Int        erruptedexception {mytask task = new MyTask ();        thread T1 = new thread (Task);        T1.setname ("T1");            Thread t2 = new Thread (Task);            T2.setname ("T2");            T1.start ();   T2.start ();    }}class MyTask implements Runnable {private Integer mutex;    Public MyTask () {mutex = 1; } @Override public void Run () {synchronized (mutex) {while (true) {System.out.pri                Ntln (Thread.CurrentThread (). GetName ());                try {TimeUnit.SECONDS.sleep (5); } catch (Interruptedexception e) {//TODO auto-generated catch block e.printstacktr                Ace (); }             }         }    }}

Thread State:

"T2" prio=10 tid=0x00007f7b2013a800 NID=0X67FB waiting for monitor entry [0x00007f7b17087000]java.lang.thread.state: BLOCKED (on object monitor) at Com.jiuyan.mountain.test.MyTask.run (app.java:35) – Waiting to lock <0X00000007D6B6DDB8 > (a Java.lang.Integer) at Java.lang.Thread.run (thread.java:745) "T1" prio=10 tid=0x00007f7b20139000 NID=0X67FA Waiting on condition [0x00007f7b17188000]java.lang.thread.state:timed_waiting (sleeping) at Java.lang.Thread.sleep ( Native Method)

T1 did not grab the lock, so the display BLOCKED. T2 grabbed the lock, but was in sleep, so show timed_waiting, limited wait for a certain condition to wake up.
Remove the sleep code and the thread state becomes:

"T2" prio=10 tid=0x00007fa0a8102800 nid=0x6a15 waiting for monitor entry [0x00007fa09e37a000]java.lang.thread.state: BLOCKED (on object monitor) at Com.jiuyan.mountain.test.MyTask.run (app.java:35) – Waiting to lock <0x0000000784206650 > (a Java.lang.Integer) at Java.lang.Thread.run (thread.java:745) "T1" prio=10 tid=0x00007fa0a8101000 nid=0x6a14 runnable [0x00007fa09e47b000]java.lang.thread.state:runnable at Java.io.FileOutputStream.writeBytes (Native Method)

T1 display RUNNABLE, instructions are running, here is an additional explanation, if this thread is querying the database, but the database deadlock, although the thread appears to be running, and actually does not work, for the IO-type thread only use the thread state to determine whether the work is normal.
Change the MyTask code a little bit, the thread gets the lock, executes wait, releases the lock, and enters the waiting area.

public void Run () {    synchronized (mutex) {        if (mutex = = 1) {            try {                mutex.wait ();            } catch (Interruptede Xception e) {                //TODO auto-generated catch block                e.printstacktrace ();            }        }     }

The thread status is as follows:

"T2" prio=10 tid=0x00007fc5a8112800 nid=0x5a58 in object.wait () [0x00007fc59b58c000]java.lang.thread.state:waiting ( on object monitor) at java.lang.Object.wait (Native Method) "T1" prio=10 tid=0x00007fc5a8111000 nid=0x5a57 in Object.wait ( ) [0x00007fc59b68d000]java.lang.thread.state:waiting (on Object monitor) at java.lang.Object.wait (Native Method)

Two threads all display waiting, this time is indefinite, need to regain the lock, so followed by on object Monitor.

Another example of a deadlock:

Package Com.jiuyan.mountain.test;import java.util.concurrent.timeunit;/*** Hello world!* */public class App {public S           tatic void Main (string[] args) throws Interruptedexception {MyTask Task1 = new MyTask (true);           MyTask Task2 = new MyTask (false);           thread T1 = new Thread (TASK1);           T1.setname ("T1");           Thread t2 = new Thread (TASK2);           T2.setname ("T2");           T1.start ();     T2.start ();     }}class MyTask implements Runnable {private Boolean flag;     Public MyTask (Boolean flag) {This.flag = flag;                       } @Override public void Run () {if (flag) {synchronized (MUTEX.MUTEX1) {                       try {TimeUnit.SECONDS.sleep (1);                             } catch (Interruptedexception e) {//TODO auto-generated catch block                       E.printstacktrace (); } SynchronizEd (mutex.mutex2) {System.out.println ("OK");                             }}} else {synchronized (MUTEX.MUTEX2) {try {                       TimeUnit.SECONDS.sleep (1);                             } catch (Interruptedexception e) {//TODO auto-generated catch block                       E.printstacktrace ();                       } synchronized (MUTEX.MUTEX1) {System.out.println ("OK");    }}}}}class Mutex {public static Integer mutex1 = 1; public static Integer mutex2 = 2;}

Thread Status:

"T2" prio=10 tid=0x00007f5f9c122800 nid=0x3874 waiting for monitor entry [0x00007f5f67efd000]java.lang.thread.state: BLOCKED (on object monitor) at Com.jiuyan.mountain.test.MyTask.run (app.java:55) – Waiting to lock <0x00000007d6c45bd8 > (a java.lang.Integer)-locked <0x00000007d6c45be8> (a Java.lang.Integer) at Java.lang.Thread.run ( thread.java:745) "T1" prio=10 tid=0x00007f5f9c121000 nid=0x3873 waiting for monitor entry [0x00007f5f67ffe000] Java.lang.Thread.State:BLOCKED (on object monitor) at Com.jiuyan.mountain.test.MyTask.run (app.java:43) – Waiting to Lock <0x00000007d6c45be8> (a java.lang.Integer)-locked <0x00000007d6c45bd8> (a java.lang.Integer) at Java.lang.Thread.run (thread.java:745) Found one java-level deadlock:============================= "T2": Waiting to  Lock monitor 0x00007f5f780062c8 (Object 0x00000007d6c45bd8, a Java.lang.Integer), which is held by "T1" "T1": Waiting to lock Monitor 0x00007f5f78004ed8 (Object 0x00000007d6c45be8, a java.lang.Integer), WHIch is held by "T2" 

It's kind of like a philosopher's meal, and each thread holds the lock the other person needs, and that's not going to work.

Two basic principles of tuning Strategy:
    • The number of objects to be transferred to the old age is minimized.
    • Reduce the execution time of full GC. The goal is to minor GC time within 100MS and full gc time within 1s.
Main tuning Parameters:

Set the heap memory size, which is the most basic.

    1. -XMS: Heap memory space When the JVM is started.
    2. -XMX: Maximum heap memory limit.

Sets the Cenozoic size.

The new generation should not be too small, otherwise there will be a large number of objects pouring into the old age.

    1. -xx:newratio: The proportion of the new generation and the old age.
    2. -xx:newsize: Cenozoic space.
    3. -xx:survivorratio: The proportion of Eden space and survivor space.
    4. -xx:maxtenuringthreshold: Age threshold for objects entering the old age.

Setting up the garbage collector

Young generation:-XX:+USEPARNEWGC.

Old age:-XX:+USECONCMARKSWEEPGC.

CMS can minimize STW time, but does not compress memory, there is a possibility of "parallel mode failure". For example, the old age space has 300MB space, but some 10MB objects cannot be stored sequentially. Compression processing is triggered, but the compression processing time in CMS GC mode is much longer than the parallel GC.

G1 uses the "mark-and-organize" algorithm to solve the memory fragmentation problem and establish a predictable pause-time type, which allows the user to specify a time period of M milliseconds to consume less than n milliseconds for garbage collection.

JVM Performance Tuning Getting Started Guide

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.