notes:
1.top order to find the highest occupied by the process (command as java)
2. Look under high load thread high-load process: top -Hp [PID] ( or PS -mp PID -o THREAD, tid, Time )
3. Find and record the highest occupied by the thread thread_id, the thread number for conversion into hexadecimal numbers: printf "the X-% \ the n-" thread_id
4. (Optional) Check the thread name high load: jstack 16143 [process] | grep 3fb6 [thread]
The export process stack logs, find 3fb6 this thread number: jstack 16143> /home/16143.log
. PS Other commands may be used:
1. Input: top -H -p PID or ps -mp PID -o THREAD, tid, time
Find the highest occupied by the thread and record thread_id
2. Check dump information (-a 30 meaning print 30 lines)
jstack pid | grep 16 hex thread_id -a 30
Or export
jstack pid | grep 16 hex thread_id -a 30> xx.log
Case record:
Positioning: According to the feedback operation and maintenance CPU load is very high, initially determined that the application code question, a thread in the long run, CPU resources, such as the cycle of death and so on.
1, execution: top
View high-load process
2、top -Hp 16143
View high thread load under high load process
The thread number 16310 were converted to hexadecimal number: 3fb6
3, jstack 16143 | grip 3fb6
Execution thread name to view high load
According inquiry to get to know the name of the thread is a message thread high consumer load.
4、jstack 16143 >/home/16143.log
The export process stack logs, find 3fb6 this thread No.
By tracking code, confirmation code method in question.
Fourth, bug fixes
1, update operation using the select statement
2, modify the type of update, submitted solve
V. Summary
1, because it is a step in the thread, so monitoring platform can not monitor the specific lines of code
2, the thread has stuck, do not have any information suggesting log
3, is a typical need to get through the stack to print the investigation have high load problem