JDK provides command tools
to stand
It is a command-line tool for monitoring various running status information of virtual machines. It can display the running data such as class loading, memory, garbage collection, JIT compilation, etc. in the local or remote virtual machine process. On a server that only provides a plain text console environment without a GUI graphical interface, it will be a virtual The tool of choice for machine performance problems.
grammar:
jstat -option pid
The option parameters are as follows:
-class (class loader)
-compiler (JIT)
-gc (GC heap status)
-gccapacity (size of each district)
-gccause (last GC statistics and reasons)
-gcnew (new district statistics)
-gcnewcapacity ( New area size)
-gcold (old area statistics)
-gcoldcapacity (old area size)
-gcpermcapacity (permanent area size)
-gcutil (GC statistics summary)
-printcompilation (HotSpot compilation statistics)
Check the GC status command:
jstat -gc pid 250 10
The last two parameters represent a query every 250 milliseconds, a total of 10 queries.
Return value column meaning:
S0C : size of the first survivor area (From area)
S1C : size of the second survivor area (To area)
S0U : usage size of the first survivor area
S1U : usage of the second survivor area Size
EC : size of (Eden) area
EU : size of (Eden) area used
OC : size of old generation
OU : size of old generation
MC : size of method area
MU : size of method area used
CCSC : size of compressed class space
CCSU : size of compressed class Space usage size
YGC : Young generation garbage collection times
YGCT : Young generation garbage collection time
FGC : Old generation garbage collection times
FGCT : Old generation garbage collection time
GCT : Garbage collection total time
jinfo
View and modify the parameters of the virtual machine.
Check whether the production environment program prints the GC log command as follows:
jinfo -flag PrintGC java进程Id
Output -XX:-PrintGC is off, output -XX:+PrintGC is on.
Dynamically enable GC log command:
jinfo -flag +PrintGC java进程Id
Dynamically close the GC log command:
jinfo -flag -PrintGC java进程Id
jmap
Used to generate heap dump snapshots (commonly known as heapdump or dump files). The role of jmap is not only to obtain dump files, it can also query the details of the finalize execution queue, Java heap and permanent generation, such as space usage, which collector is currently used, and so on. Like the jinfo command, jmap has many functions that are limited under the Windows platform, except the -dump option for generating dump files and the -histo option for viewing instances and space occupancy statistics of each class are available on all operating systems. Unless provided, the remaining options are only available under Linux/Solaris.
Print heap summary information:
jmap –heap <pid>
Return value meaning:
Heap Configuration: ##Heap configuration, which is the result of JVM parameter configuration [usually tomcat configures JVM parameters, is configuring these]
MinHeapFreeRatio = 40 ##Minimum heap usage ratio
MaxHeapFreeRatio = 70 ##Maximum heap Available ratio
MaxHeapSize = 2147483648 (2048.0MB) ##Maximum heap space size
NewSize = 268435456 (256.0MB) ## New generation allocation size
MaxNewSize = 268435456 (256.0MB) ## Maximum new generation allocation size
OldSize = 5439488 (5.1875MB) ##Old age size
NewRatio = 2 ##The ratio of the new generation
SurvivorRatio = 8 ##The ratio of the new generation to survivor
PermSize = 134217728 (128.0MB) ##Perm area permanent generation size
MaxPermSize = 134217728 (128.0MB) ##The largest allocation The perm area is also the size of the permanent generation
Heap Usage: ##Heap usage [actual usage of heap memory]
New Generation (Eden + 1 Survivor Space): ##New generation (Eden area Eden area + survivor area survivor(1+ 2) Space)
capacity = 241631232 (230.4375MB) ##Eden area capacity
used = 77776272 (74.17323303222656MB) ##Used size
free = 163854960 (156.26426696777344MB) ##Remaining capacity
32.188004570534986% used ##Use ratio
Eden Space: ##Eden area
capacity = 21 4827008 (204.875MB) ##Eden District Capacity
used = 74442288 (70.99369812011719MB) ##Eden area usage
free = 140384720 (133.8813018798828MB) ##Eden area current remaining capacity
34.65220164496263% used ##Eden area usage
From Space: ##survior Zone 1
capacity = 26804224 ( 25.5625MB) ##survior1 area capacity
used = 3333984 (3.179534912109375MB) ##surviror1 area used
free = 23470240 (22.382965087890625MB) ##surviror1 area remaining capacity
12.438278384 77995% used ##survior1
To Space: ##survior2 Area
capacity = 26804224 (25.5625MB) ##survior2 area capacity
used = 0 (0.0MB) ##survior2 area used
free = 26804224 (25.5625MB) ##survior2 area remaining capacity
0.0% used ##survior2 area usage ratio
PS Old Generation: ##old generation usage
capacity = 1879048192 (1792.0MB) ##old generation capacity
used = 30847928 (29.4188766479 4922MB ) ##Old generation used capacity
free = 1848200264 (1762.5811233520508MB) ##Old generation remaining capacity
1.6416783843721663% used ##Old generation usage ratio
Print the number of instances of each class, memory usage, and class full name information. The command is as follows:
jmap –histo <pid>
jmap –histo:live <pid> #如果 live 子参数加上后,只统计活的对象数量.
jmap –histo pid | head -20 #只显示前20
Generate heap dump file command:
jmap -dump:live,format=b,file=heap.bin <pid>
Jhat
Load dump file command:
jhat dump 文件名
After the prompt of "Server is ready." is displayed on the screen, the user can type http://localhost:7000/ in the browser to access the details. Use
jhat to generate a heap dump file on the server for analysis (generally not recommended, after all, it takes up The resources of the server, for example, if a file has 1 G, it needs to eat a memory resource of about 1G).
Dump is a memory snapshot, which can be viewed through the dump file.
jstack
Generally speaking, jstack is mainly used to check whether there is a deadlock.
JVM tuning solution
Turn on related parameters
-XX:-HeapDumpOnOutOfMemoryError is disabled by default. It is recommended to enable it. When a java.lang.OutOfMemoryError exception occurs, a dump file will be output to record the heap memory snapshot at that time.
-XX:HeapDumpPath=./java_pid.hprof is used to set the storage file path of the heap memory snapshot, and the default is the start location of the java process.
Arthas
Arthas is Alibaba's open source Java diagnostic tool, which is loved by developers. Arthas supports JDK 6+, supports Linux/Mac/Windows, adopts the command line interactive mode, and provides a wealth of Tab auto-completion functions, which further facilitates problem location and diagnosis. Here is a brief introduction of its functions, and specific usage
needs Experience in actual combat.
The dashboard command, the panel functions are as follows:
thread command:
this command is similar to jstack, but more powerful, mainly to view the thread stack information of the current JVM. At the same time, thread -b can be used in combination to troubleshoot deadlocks.
Parameter explanation:
-n specifies the busiest top n threads and prints the stack
-b finds the thread that blocks the current thread
-i specifies the sampling interval of the cpu ratio statistics, in milliseconds.
jad command:
decompile the source code of the specified loaded class, specify the full path name of the class, decompile the source code of the class, and troubleshoot problems in the production environment.
Trace command:
Use the trace command to track the time-consuming of statistical methods.
Command summary:
Choose an Appropriate Garbage Collector
The default garbage collector has a long STW time. For high-performance systems, you can use the CMS or G1 garbage collector to reduce the STW time and improve performance.
GC tuning strategy
- Reduce Minor GC frequency
Since the young generation space is small, the Eden area will be filled quickly, which will lead to frequent Minor GC, so we can reduce the frequency of Minor GC by increasing the young generation space. A single Minor GC time is composed of two parts: T1 (scanning the new generation) and T2 (copying surviving objects).
In the JVM, the cost of copying objects is much higher than the cost of scanning. If there are many long-lived objects in the heap memory, increasing the young generation space will increase the Minor GC time. If there are a lot of short-term objects in the heap, the time for a single Minor GC will not increase significantly when expanding the new generation. Therefore, the time of a single Minor GC depends more on the number of surviving objects after GC, rather than the size of the Eden area.
- Reduce the frequency of Full GC.
Due to insufficient heap memory space or too many objects in the old age, Full GC will be triggered. Frequent Full GC will bring about context switching and increase the performance overhead of the system. Reduce the frequency of Full GC by reducing the creation of large objects and increasing the heap memory space.
The difference between memory overflow and memory leak
Memory overflow: simply because the memory is not enough, usually an error Out of Memory is reported.
Memory leak: Useless objects in memory cannot be cleared by gc, and occupy memory space all the time, which is called memory leak. A memory leak does not necessarily lead to a memory overflow, but if it keeps leaking, it will eventually cause a memory overflow.
Troubleshooting high CPU issues
- Use the top command to find out the pid of the java process with high CPU.
- Use the top -p pid command to view the processes found in step 1 individually.
- Enter H on the monitoring interface in step 2 to obtain all thread information under the current process.
- Find the thread number that consumes particularly high CPU
- Execute the jstack pid command to dump the current process and output all thread information.
- Convert the thread number obtained in step 4 to hexadecimal.
- According to the thread number obtained in step 6, find the corresponding thread content in the thread information in step 5
- Interpret the thread information and locate the specific code location.
Summary:
If the CPU is 100%, we need to start from two perspectives. One may be that the business thread is running crazily, such as thinking about many infinite loops. Another possibility is that the GC thread is recycling crazily, because the mainstream garbage collector in the JVM is also multi-threaded, so it can easily lead to 100% of the CPU
Troubleshooting Out of Memory
Memory overflow is generally caused by too many objects. You can use the following command to query which objects are too many:
jmap –histo pid | head -20
Then analyze why there are so many corresponding classes, why they will not be recycled (reachability analysis, etc.), and then further analyze the reasons.