preface
This case is a brief introduction to JVM troubleshooting tools, tuning measures, and a brief analysis of common examples. (a more complete command can refer to: docs.oracle.com/javase/7/do…).
I. Common tools
1. jmap
The jmap command is a tool that can output all the objects in memory, even the heap in the VM, as binary output to text. Prints out all ‘objects’ in memory of a Java process (using pid) (e.g., which objects were generated, and how many). Example:
- Jmap-histo $PID –> Displays statistics on objects in the heap
Instance indicates the number of elements, and bytes indicates the size of memory occupied by elements (unit: KB).
- Jamp-heap $PID –> Displays Java heap details
Attaching to process ID 31370, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.45-b02
using thread-local object allocation.
Parallel GC with 4 thread(s)
Heap Configuration:
MinHeapFreeRatio = 0
MaxHeapFreeRatio = 100
MaxHeapSize = 492830720 (470.0MB)
NewSize = 10485760 (10.0MB)
MaxNewSize = 164102144 (156.5MB)
OldSize = 20971520 (20.0MB)
NewRatio = 2
SurvivorRatio = 8
MetaspaceSize = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize = 17592186044415 MB
G1HeapRegionSize = 0 (0.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 7864320 (7.5MB)
used = 5038400 (4.80499267578125MB)
free = 2825920 (2.69500732421875MB)
64.06656901041667% used
From Space:
capacity = 5767168 (5.5MB)
used = 131072 (0.125MB)
free = 5636096 (5.375MB)
2.272727272727273% used
To Space:
capacity = 6291456 (6.0MB)
used = 0 (0.0MB)
free = 6291456 (6.0MB)
0.0% used
PS Old Generation
capacity = 117964800 (112.5MB)
used = 78530512 (74.89253234863281MB)
free = 39434288 (37.60746765136719MB)
66.57113986545139% used
Copy the code
- Jmap -dump:live,format=b,file=dumpfile $PID –> Snapshot dump files
Jmap-dump :live,format=b,file=heapdump.hprof $PID The Live suboption is optional. If the live suboption is specified, only active objects in the heap are dumped. (Execution takes time)
2. jstack
Jstack is a stack tracing tool of the Java VIRTUAL machine. Often used to analyze a threading problem, such as a deadLock between threads.
- Jstack -l $PID > / TMP /dump/jstack.log –> Export stack information
-l: Displays additional lock information
2. Find the TID of the thread that consumes the most CPU in the Java process
- Using the top command, you can find the thread with the highest CPU usage: top-h -p PID
Output can be used in detail: ps p {pid} – L – o pcpu, pid, dar, time, tname, CMD
- Convert TID to hexadecimal: printf 0x%x n
- Locate the hexadecimal data for TID from the jstack.log file
3. jstat
JVM Statistics Monitoring, a command to monitor the status of a virtual machine as it runs, which displays running data such as classloading, memory, garbage collection, JIT compilation (even if compiled) in the virtual machine process.
- Jstat -gc $PID –> get garbage collection information
Result Analysis: heap memory = young generation + Old generation + permanent generation Young generation = Eden region + two Survivor regions S0C, S1C, S0U, S1U: Survivor0/1EC, EU: Eden Capacity and Usage OC and OU: Capacity and usage of the elderly generation PC and PU: Capacity and usage of the permanent generation YGC and YGT: number and duration of GC in the young generation FGC and FGCT: Full GC count and Full GC Duration GCT: indicates the total GC durationCopy the code
Xms-xmn, -xx :NewRatio, -xx :SurvivorRatio: -- Xmn ** sets new generation size ** -- XX:NewRatio new generation (Eden +)2*s) to the old age (not including permanent areas) for example:4, stands for new generation: old age =1:4That is, the new generation occupies the entire heap1/5-- -xx :SurvivorRatio Sets the ratio of two Survivor zones to Eden. Example:8, indicating two Survivor: Eden =2:8, that is, a Survivor of the younger generation1/10
Copy the code
- GC result analysis
Average YGC time =YGCT/YGC (s) =5176.81/469204=0.011s=11ms YGC Interval =YGC/ program running time
If the parameters are set reasonably, the system does not have timeout logs, GC frequency is not high, and GC time is not high, then GC optimization is not necessary. If the GC time exceeds1~3Seconds, or frequent G C, must be optimized. GC is generally not required if the following metrics are met; ■ Minor GC execution time is less than 50ms; \ ■ Minor GC executes infrequently, about10Seconds at a time; \ ■ Full GC execution time less than 1s; \ ■ Full GC execution frequency is infrequent, no less than10minutes1Times.Copy the code