Analysis of high cpu usage of linux processes

Linux process high cpu problem analysis 1 use the top command to check which process occupies CPU high gateway process 14094 occupies CPU up to 891%. this value is the cumulative value of CPU usage by each thread in the process. Piduserprni1_resshrs % CPU % MEMTIME + linux process high cpu problem analysis 1. run the top command to check which process occupies CPU. The gateway process occupies 14094 of the CPU and reaches 891% of the CPU usage. this value is the sum of CPU usage by each thread in the process. Pid user pr ni virt res shr s % CPU % mem time + COMMAND 14094 root 15 0 315 m 10 m 7308 S 891% 2.2. 01 gateway 20642 root 17 0 17784 4148 S 2220 0.5. 96 microdasys 1679 root 18 0 10984 1856 R 1556 0.3. 21 sshd 22563 root 18 0 2424 1060 R 800 0.3. 03 top 1 root 18 0 2156 492 S 460 0.0. 59 init 2. run the top-H-p pid command to view the CPU usage of each thread in the process #107 threads can be found in top-H-p 14094top, but the following 9 Threads occupy a high CPU usage. below, the main thread is 14086, analyze why high cpu pid user pr ni virt res shr s % cpu mem time + COMMAND 14086 root 25 0 922 m 914 m 538 m R 101 10.0. 46 gateway 14087 root 25 0 922 m 914 m 538 m R 101 10.0. 22 gateway 14081 root 25 0 922 m 914 m 538 m S 99 10.0. 36 gateway 14082 root 25 0 922 m 914 m 538 m R 99 10.0. 92 gateway 14089 root 25 0 922 m 914 m 538 m R 99 10.0. 77 gateway 14092 root 25 0 92 2 m 914 m 538 m R 99 10.0. 47 gateway 14094 root 25 0 922 m 914 m 538 m R 99 10.0. 21 gateway 14083 root 25 0 922 m 914 m 538 m R 97 10.0. 39 gateway 14088 root 25 0 922 m 914 m 538 m R 97 10.0. 12 gateway 3. use the gstack command to view the function call stacks of various threads in the process # gstack 14094> gstack. log in the ststack. the log finds the Thread ID14086. because the function stack exposes the function details, only two function counters are displayed. the Thread id of Thread ID14086 is 37 Thread 37 (Thread 0x4696ab90 (LWP 14086 )): #0 0x40000410 in _ kernel _ Vsyscall () #1 0x40241f33 in poll () from/lib/i686/nosegneg/libc. so.6 4. use the gcore command to save the process image and memory context # gcore 14094. this command generates the core file core.14094 5. Use the strace command to view the system call and time spent # Complete usage of strace-T-r-c-p 14094: strace-o output.txt-T-tt-e trace = all-p $ pid the above meaning is to trace all system calls of the 28979 process (in the-e prepare file. -The c parameter displays statistics. with this parameter removed, you can view the call time and return value of each system call. % Time seconds usecs/call callerrors syscall ------ ----------- hour 99.99 22.683879 3385 6702 poll 0.00 0.001132 0 6702 gettimeofday 0.00 0.000127 1 208 accept 208 0.00 22 1 read 0.000022 0 1 write 0.00 0.000000 0 1 close 0.00 0.000000 0 14 time 0.00 0.000000 0 2 stat64 0.00 0.000000 0 4 clock_gettime 0.00 0.000000 0 7 send 0. 00 0.000000 0 10 10 recvfrom ------ ----------- --------- ------------------------------ 100.00 22.685160 13652 total 6. using gdb to debug the core file, and switching the thread to the gcore of thread 37 is almost the same as the core file generated when the actual core dump is used, but gdb cannot be used for some Dynamic Debugging (gdb) gdb gateway core.14094 (gdb) thread 37 [Switching to thread 37 (Thread 0x4696ab90 (LWP 14086)] #0 0x40000410 in _ kernel_vsyscall () (gdb) where #0 0x40000410 in _ kernel_vsysc All () #1 0x40241f33 in poll () from/lib/i686/nosegneg/libc. so.6 can debug gdb based on the detailed function stack, print some variable values, and analyze with the source code why poll calls occupy a high CPU.