Analysis of the reason why java takes up a lot of CPU resources in centos

Keywords: Java jvm

Find thread PID

1. Use the top command to find the PID of the java process. The PID I found here is 13520

Locating thread

After finding the process, locate the specific thread or code. First, display the list of threads, and sort them according to the threads with high CPU consumption:

ps -mp 13017 -o THREAD,tid,time | sort -rn

root># ps -mp 13017 -o THREAD,tid,time | sort -rn
USER     %CPU PRI SCNT WCHAN  USER SYSTEM   TID     TIME
root     99.9  19    - -         -      - 13520 14:44:09
root      100   -    - -         -      -     - 14:52:22
root      0.6  19    - futex_    -      - 13519 00:05:41
root      0.0  19    - skb_wa    -      - 29473 00:00:00
root      0.0  19    - poll_s    -      - 13018 00:00:00
root      0.0  19    - inet_c    -      - 13515 00:00:00
...

Thread ID converted to hex format

root># printf "%x" 13520
34d0

Stack information for print threads

Finally, use the jvm command to print the stack information of the thread:

jstack 13017 |grep 34d0 -A 30

root># jstack 13017 |grep 34d0 -A 30
"SysLogManager" #74 daemon prio=5 os_prio=0 tid=0x00007f0250239800 nid=0x34d0 runnable [0x00007f022117d000]
   java.lang.Thread.State: RUNNABLE
	at com.rd.ifaes.common.syslog.SysLogManager.run(SysLogManager.java:84)

"System Clock" #73 daemon prio=5 os_prio=0 tid=0x00007f024c13a800 nid=0x34cf waiting on condition [0x00007f022147e000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007bbae3e00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

"Thread-10" #72 daemon prio=5 os_prio=0 tid=0x00007f024c0a7800 nid=0x34ce waiting on condition [0x00007f022157f000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007bbb57948> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

"Thread-9" #71 daemon prio=5 os_prio=0 tid=0x00007f025017f800 nid=0x34cd waiting on condition [0x00007f0221680000]

In this way, we can find the code that takes up java and cpu resources. Next, we have to analyze the reason for code execution.

Posted by shivam0101 on Thu, 09 Apr 2020 11:15:10 -0700