Linux CPU occupancy rate Analysis __linux

Http://blog.leanote.com/post/github-yihengliucc/linux-cpu%E5%8D%A0%E7%94%A8%E7%8E%87%E5%88%86%E6%9E%90

Use the top command to see that there may be a very high rate of process occupancy, which is the cumulative amount of CPU accumulated by each thread in the process.

The understanding of the third line of CPU (s) is:
%us user space consumes a percentage of the CPU, and when there is more than one CPU, the denominator is the sum of all CPU computing power.
%sy kernel space consumes the CPU percent, and when there are multiple CPUs, the denominator is the sum of all CPU computing power.
The CPU utilization of a single process is understood to be:
The current task share the CPU time from the last screen refresh, expressed as a percentage of the total CPU time. In a real SMP environment, if IRIX mode is set to Off,top will work under Solaris mode, that is, the CPU utilization of a task will be shown separately from the total number of CPUs, to toggle Irix/solaris Mode, press I.
For example, the process consumes the total CPU usage sum is 10%, the top command displays the result is 160% (10%*16 core), so the current picture in the actual use of Tomcat CPU total utilization rate is 106%/16=6.625% and host overall load basically consistent.

PID user PR NI virt RES SHR S%cpu%mem time+ COMMAND 14094 root 0 315m 10m 7308 S 891% 2.2 The gateway uses 1:49.01 p PID commands can see how many threads in the process are consuming CPU percent

Top can be seen with 107 threads, but the following 9 threads occupy a high CPU, following thread 14086 as the main, to analyze why the high CPU PID USER PR NI virt RES SHR S%cpu MEM time+ COMMAND 14086 Root 0 922m 914m 538m R 10.0 21:35.46 Gateway 14087 root 0 922m 914m 538m R 10.0 10:50.22 Gateway 14081 Root 25 0 922m 914m 538m S 10.0 8:57.36 Gateway Use command Gstack to view function call stacks for each thread in a process
Gstack pid > Gstack.log, here's the PID is detected above

#gstack 14094 > Gstack.log Find Threads in Gstack.log ID14086, because the function stack exposes function details, so only two function frames are displayed, thread ID14086 corresponds to the thread number is Panax Notoginseng (thread 0x4696ab90 (LWP 14086)): #0 0x40000410 in __kernel_vsyscall () #1 0x40241f33 in poll () from/lib/i686/nosegneg/libc.so.6 Use command Gcore to dump process image and memory context
Gcore pid change command to generate Core.pid file

#gcore 14094 This command generates core files core.14094 use the Strace command to view system calls and time spent
Strace-t-r-c-P pid,-c parameters display statistics, which can be removed to view the time and return value of each system call.

% time seconds Usecs/call calls errors syscall---------------------------------------------------------------------- ----99.99 22.683879 3385 6702 poll debug core files with GDB, and the thread switches to number 37th (the process number can be seen in the Gstack command) thread

Gcore is almost the same as the core file produced by the actual core dump, but you cannot use GDB for some dynamic debugging (GDB) GDB Gateway core.14094 (GDB) thread Notoginseng [switching to Thread (T Hread 0x4696ab90 (LWP 14086))] #0 0x40000410 in __kernel_vsyscall () (GDB) where #0 0x40000410 in __kernel_vsyscall () #1 0 X40241f33 in poll () From/lib/i686/nosegneg/libc.so.6 can be based on a detailed function stack for GDB debugging, printing some variable values, and combined with the source code analysis of why the poll call to occupy a very high CPU. Because the code involves the company property rights, Gu does not do detailed analysis here, need to understand is the analysis of the flow and use of the command.