JVM Performance Tuning Getting Started Guide

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