短时进程–消耗CPU的元凶
一 问题现象
通常情况下，系统CPU资源使用率高的话，我们可以通过top查看到消耗CPU资源的进程，进而分析该进程。但是，在有些时候，我们通过top明明看到系统CPU使用率非常高，却看不到消耗CPU资源的进程。如下：
[root@localhost ~]# top
top - 08:45:36 up 15:45, 4 users, load average: 4.17, 1.30, 1.67
Tasks: 219 total, 8 running, 211 sleeping, 0 stopped, 0 zombie
%Cpu(s): 74.9 us, 20.3 sy, 0.0 ni, 2.5 id, 0.0 wa, 0.0 hi, 2.3 si, 0.0 st
KiB Mem : 3881344 total, 733212 free, 905640 used, 2242492 buff/cache
KiB Swap: 4063228 total, 4061940 free, 1288 used. 2068120 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6011 101 20 0 34020 2964 756 R 3.9 0.1 0:51.10 nginx
2071 oracle 20 0 3460008 208668 78060 S 2.6 5.4 101:47.43 gnome-shell
12897 bin 20 0 336684 7644 1876 S 2.6 0.2 0:01.46 php-fpm
12904 bin 20 0 336684 7644 1872 S 2.6 0.2 0:01.45 php-fpm
12909 bin 20 0 336684 7644 1872 S 2.3 0.2 0:01.42 php-fpm
12915 bin 20 0 336684 7644 1868 S 2.3 0.2 0:01.45 php-fpm
12923 bin 20 0 336684 7644 1868 S 2.3 0.2 0:01.41 php-fpm
468 root 20 0 55804 19716 19128 S 2.0 0.5 0:52.49 systemd-journal
5965 root 20 0 275716 2972 1660 S 1.6 0.1 0:17.45 docker-containe
1724 oracle 0 -20 1497560 161316 70728 S 1.3 4.2 52:35.72 nxnode.bin
5725 root 20 0 809180 32824 14876 S 1.3 0.8 0:23.48 dockerd-current
9 root 20 0 0 0 0 S 0.3 0.0 0:41.19 rcu_sched
900 root 20 0 0 0 0 R 0.3 0.0 0:00.29 kworker/0:0
953 nx 20 0 1436212 78652 7484 S 0.3 2.0 2:46.69 nxserver.bin
2534 oracle 20 0 1166020 82632 42852 S 0.3 2.1 14:44.10 gnome-initial-s
5731 root 20 0 394008 11468 5604 S 0.3 0.3 0:03.93 docker-containe
21972 root 20 0 162136 2324 1512 R 0.3 0.1 0:00.08 top
25557 bin 20 0 8172 860 104 R 0.3 0.0 0:00.01 stress
25562 bin 20 0 8176 596 104 R 0.3 0.0 0:00.01 stress
1 root 20 0 193976 6912 4116 S 0.0 0.2 0:06.26 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.06 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:01.52 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
7 root rt 0 0 0 0 S 0.0 0.0 0:00.41 migration/0明明74.9 us和20.3 sy,加起来已经非常之高了。却看不到过分消耗CPU资源的进程？
二 故障现象重现
1 准备机器
机器1：172.16.11.148, 2 CPU，4G内存，用于模拟服务端机器，运行docker，跑php+nginx的服务，接收客户端机器发起的请求，待会儿会看到该机器的CPU非常高，却看不到哪些进程消耗了CPU的情况；
机器2：172.16.11.195，充当客户端机器，通过运行Apache的web性能测试工具ApacheBench，向机器1,172.16.11.148发起请求。
2 服务端启动docker进程
172.16.11.148机器：
[root@localhost ~]# docker run --name nginx -p 10000:80 -itd feisky/nginx:sp 337a986d71b09227072d3c7fa75e860d454703b9cd7ae10c9a3f7dfa6622f618 [root@localhost ~]# docker run --name phpfpm -itd --network container:nginx feisky/php-fpm:sp 4fe260d1df8a7ad7fedb392b70172957896ca7f906c552b99483be2a142613ec [root@localhost ~]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 4fe260d1df8a feisky/php-fpm:sp "php-fpm -F --pid ..." 3 seconds ago Up 2 seconds phpfpm 337a986d71b0 feisky/nginx:sp "nginx -g 'daemon ..." 9 seconds ago Up 9 seconds 0.0.0.0:10000->80/tcp nginx [root@localhost ~]#
3 客户端发起web压力测试请求
172.16.11.195机器：
[root@localhost ~]# curl http://172.16.11.148:10000
It works![root@localhost ~]#
[root@localhost ~]# ab -c 100 -n 1000 http://172.16.11.148:10000/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 172.16.11.148 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: nginx/1.15.4
Server Hostname: 172.16.11.148
Server Port: 10000
Document Path: /
Document Length: 9 bytes
Concurrency Level: 100
Time taken for tests: 14.196 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 172000 bytes
HTML transferred: 9000 bytes
Requests per second: 70.44 [#/sec] (mean)
Time per request: 1419.645 [ms] (mean)
Time per request: 14.196 [ms] (mean, across all concurrent requests)
Transfer rate: 11.83 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 5 63.2 0 1001
Processing: 41 1346 277.9 1358 1750
Waiting: 41 1346 278.0 1358 1750
Total: 48 1351 286.0 1359 2524
Percentage of the requests served within a certain time (ms)
50% 1359
66% 1431
75% 1499
80% 1528
90% 1617
95% 1660
98% 1702
99% 1710
100% 2524 (longest request)
[root@localhost ~]# 4 服务端监控性能
在客户端发起web压力测试请求的过程中，在服务器上执行top,pidstat监控系统资源情况：
[root@localhost ~]# top
top - 11:12:46 up 18:12, 4 users, load average: 3.18, 0.98, 0.40
Tasks: 221 total, 5 running, 216 sleeping, 0 stopped, 0 zombie
%Cpu(s): 75.0 us, 21.3 sy, 0.0 ni, 1.8 id, 0.0 wa, 0.0 hi, 1.8 si, 0.0 st
KiB Mem : 3881344 total, 675232 free, 897368 used, 2308744 buff/cache
KiB Swap: 4063228 total, 4061940 free, 1288 used. 2039008 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16015 101 20 0 34016 2960 756 S 4.3 0.1 0:01.84 nginx
22852 bin 20 0 336684 7652 1880 S 2.6 0.2 0:00.71 php-fpm
22862 bin 20 0 336684 7648 1872 S 2.6 0.2 0:00.72 php-fpm
22881 bin 20 0 336684 7648 1868 S 2.3 0.2 0:00.69 php-fpm
468 root 20 0 63992 21316 20728 S 2.0 0.5 1:14.91 systemd-journal
22867 bin 20 0 336684 7644 1868 S 2.0 0.2 0:00.66 php-fpm
22872 bin 20 0 336684 7648 1868 S 2.0 0.2 0:00.66 php-fpm
2071 oracle 20 0 3460008 208668 78060 S 1.7 5.4 117:30.89 gnome-shell
5725 root 20 0 809180 30652 15068 S 1.7 0.8 0:55.57 dockerd-current
15973 root 20 0 339844 2968 1692 S 1.3 0.1 0:00.65 docker-containe
1724 oracle 0 -20 1497560 161316 70728 S 1.0 4.2 60:21.87 nxnode.bin
16042 root 20 0 336300 33092 27700 S 0.7 0.9 0:01.03 php-fpm
9 root 20 0 0 0 0 R 0.3 0.0 0:49.11 rcu_sched
622 root 20 0 21680 1284 964 S 0.3 0.0 0:05.67 irqbalance
653 root 20 0 555148 9312 7072 S 0.3 0.2 1:33.56 NetworkManager
953 nx 20 0 1436448 78664 7484 S 0.3 2.0 3:12.94 nxserver.bin
2534 oracle 20 0 1166020 82632 42852 S 0.3 2.1 17:00.89 gnome-initial-s
22849 root 20 0 0 0 0 S 0.3 0.0 0:00.02 kworker/0:1
28953 bin 20 0 8176 864 104 R 0.3 0.0 0:00.01 stress
28955 bin 20 0 8176 864 104 R 0.3 0.0 0:00.01 stress
1 root 20 0 193976 6924 4116 S 0.0 0.2 0:06.88 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.07 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:01.92 ksoftirqd/0 以及：pidstat和vmstat
[root@localhost ~]# vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 10 0 1288 665536 544 2315556 0 0 22 17 13 15 11 2 88 0 0 9 0 1288 665656 544 2315660 0 0 0 0 3901 4014 79 20 1 0 0 8 0 1288 663892 544 2315796 0 0 0 208 4242 3969 75 22 3 0 0 6 0 1288 664892 544 2315968 0 0 0 0 4319 4087 74 23 3 0 0 6 0 1288 664596 544 2315936 0 0 0 0 4253 3726 76 23 1 0 0 11 0 1288 665104 544 2316200 0 0 0 0 4130 3913 76 23 1 0 0 5 0 1288 663400 544 2316280 0 0 0 0 4048 4230 78 21 2 0 0 7 0 1288 663856 544 2316376 0 0 0 8 4588 4416 74 22 4 0 0 8 0 1288 663892 544 2316476 0 0 0 0 4171 3454 77 23 0 0 0 8 0 1288 664032 544 2316648 0 0 0 0 4247 3804 74 24 2 0 0 ^C [root@localhost ~]#
此时，只能看到系统CPU利用率非常高，却并没有看到消耗CPU非常高的进程。
但是，从top中看到有Tasks 5 running，以及vmstat 看到CPU的r队列一直维持在比较高的数值。同时 ，top里也看到有状态为R的进程是stress，且数量只有2个左右，这并没有达到5个左右。进程pid分别是28953，28955.
三 问题分析
1 跟进分析状态为R的进程
[root@localhost ~]# ps -ef|grep 28953 root 19064 6076 0 11:21 pts/4 00:00:00 grep --color=auto 28953 [root@localhost ~]# ps -ef|grep 28955 root 19645 6076 0 11:21 pts/4 00:00:00 grep --color=auto 28955 [root@localhost ~]#
此时，并没有看到状态为R的进程28953，28955的相信信息。也就是说，这两个进程可能很快就执行完了，一闪而过。或者这进程在不停重启。
于是，可以继续观察top的输出结果，果然，状态为R的进程stress，其进程号又不停的发生了变化。
2 进程pid不断变化可能的原因
- 第一个原因，进程在不停地崩溃重启，比如因为段错误、配置错误等等，这时，进程在退出后可能又被监控系统自动重启了。
- 第二个原因，这些进程都是短时进程，也就是在其他应用内部通过 exec 调用的外面命令。这些命令一般都只运行很短的时间就会结束，你很难用 top 这种间隔时间比较长的工具发现（上面的案例，我们碰巧发现了）。
3 利用pstree查看进程树关系
[root@localhost ~]# pstree|grep stress
| | |-docker-containe-+-php-fpm-+-php-fpm---sh---stress---stress
| | | | `-2*[php-fpm---sh---stress]
[root@localhost ~]# pstree|grep stress
| | |-docker-containe-+-php-fpm-+-php-fpm---sh---stress---stress
[root@localhost ~]# 果然，看到stress进程跟我们服务端的web服务相关。
4 分析docker web程序的配置
[root@localhost ~]# docker cp phpfpm:/app .
[root@localhost ~]# grep 'stress' -r app
app/index.php:// fake I/O with stress (via write()/unlink()).
app/index.php:$result = exec("/usr/local/bin/stress -t 1 -d 1 2>&1", $output, $status);
[root@localhost ~]# cat app/index.php
<?php
// fake I/O with stress (via write()/unlink()).
$result = exec("/usr/local/bin/stress -t 1 -d 1 2>&1", $output, $status);
if (isset($_GET["verbose"]) && $_GET["verbose"]==1 && $status != 0) {
echo "Server internal error: ";
print_r($output);
} else {
echo "It works!";
}
?>[root@localhost ~]# 到这里，基本找到源头了。原来是我们用于模拟服务器端web服务中的php文件中的测试程序出的问题，
$result = exec(“/usr/local/bin/stress -t 1 -d 1 2>&1”, $output, $status);
在客户端新开一个会话，执行：
[root@localhost ~]# curl http://172.16.11.148:10000?verbose=1
Server internal error: Array
(
[0] => stress: info: [1218] dispatching hogs: 0 cpu, 0 io, 0 vm, 1 hdd
[1] => stress: FAIL: [1219] (563) mkstemp failed: Permission denied
[2] => stress: FAIL: [1218] (394) <-- worker 1219 returned error 1
[3] => stress: WARN: [1218] (396) now reaping child worker processes
[4] => stress: FAIL: [1218] (400) kill error: No such process
[5] => stress: FAIL: [1218] (451) failed run completed in 0s
)
[root@localhost ~]# 客户端每次发送一个请求时，就执行了index.php文件，该文件中执行了上述代码：
$result = exec(“/usr/local/bin/stress -t 1 -d 1 2>&1”, $output, $status);
由于失败了，马上报错，退出，再请求，再次执行stress命令，又报错失败了。这样就简单理解为恶性循环，就相当于是stress进程不停重启。进而导致CPU使用率非常之高，而我们又看不到消耗CPU资源的进程信息。
5 佐证分析
我们可以使用前面的perf -g record;perf report来分析系统性能问题。
[root@localhost ~]# perf report
Samples: 114K of event 'cycles', Event count (approx.): 66848389319
Children Self Command Shared Object Symbol
+ 4.25% 0.39% stress [kernel.kallsyms] [k] page_fault ◆
+ 3.86% 0.02% stress [kernel.kallsyms] [k] do_page_fault ▒
+ 3.79% 0.09% stress [kernel.kallsyms] [k] __do_page_fault ▒
+ 3.56% 0.21% stress [kernel.kallsyms] [k] handle_mm_fault ▒
+ 3.51% 0.00% php-fpm libc-2.24.so [.] 0x00007fc4227e5c71 ▒
+ 3.18% 0.00% php-fpm libc-2.24.so [.] 0x00007fc42283538b ▒
+ 3.15% 0.09% stress [kernel.kallsyms] [k] handle_pte_fault ▒
+ 3.10% 0.00% php-fpm [kernel.kallsyms] [k] stub_clone ▒
+ 3.10% 0.00% php-fpm [kernel.kallsyms] [k] sys_clone ▒
+ 3.10% 0.00% php-fpm [kernel.kallsyms] [k] do_fork ▒
+ 3.05% 0.02% php-fpm [kernel.kallsyms] [k] copy_process ▒
3.03% 3.03% stress libc-2.24.so [.] 0x0000000000036387 ▒
2.99% 2.99% stress stress [.] 0x0000000000002f14 ▒
+ 2.89% 0.26% php-fpm [kernel.kallsyms] [k] dup_mm ▒
+ 2.87% 0.00% php-fpm libc-2.24.so [.] 0x00007fc422835647 ▒
+ 2.87% 0.00% php-fpm [kernel.kallsyms] [k] stub_execve ▒
+ 2.87% 0.00% php-fpm [kernel.kallsyms] [k] sys_execve ▒
+ 2.86% 0.00% php-fpm [kernel.kallsyms] [k] do_execve_common.isra.24 ▒
+ 2.64% 0.00% php-fpm [unknown] [.] 0x6cb6258d4c544155 ▒
+ 2.64% 0.00% php-fpm libc-2.24.so [.] 0x00007fc42279d2e1 ▒
+ 2.50% 0.00% php-fpm [kernel.kallsyms] [k] search_binary_handler ▒
+ 2.49% 0.00% php-fpm [kernel.kallsyms] [k] load_elf_binary ▒
+ 2.39% 0.00% php-fpm [kernel.kallsyms] [k] flush_old_exec ▒
+ 2.38% 0.00% php-fpm [kernel.kallsyms] [k] mmput ▒
+ 2.36% 0.01% php-fpm [kernel.kallsyms] [k] exit_mmap ▒
+ 2.33% 0.01% stress [kernel.kallsyms] [k] tracesys ▒
+ 1.90% 0.08% stress [kernel.kallsyms] [k] apic_timer_interrupt ▒
1.80% 1.80% stress stress [.] 0x0000000000002eff ▒
+ 1.78% 0.01% stress [kernel.kallsyms] [k] smp_apic_timer_interrupt ▒
+ 1.74% 0.06% stress [kernel.kallsyms] [k] __alloc_pages_nodemask ▒
1.73% 1.73% stress stress [.] 0x0000000000002ee5 ▒
1.67% 1.67% stress libc-2.24.so [.] 0x0000000000036829 6 补充查看
由于在172.16.11.148这台机器上看到的perf report结果不是特别直观，见上述。可以，通过把perf采集的perf.data文件cp到当前机器上的docker容器phpfpm里，在这个docker容器里跑的是Debian系统，在它上面进行安装软件包，看的效果就很明显了。
当前机器172.16.11.148机器上perf -g record命令采集的数据perf.data [root@localhost ~]# pwd /root [root@localhost ~]# ll perf.data -rw------- 1 root root 20755944 9月 16 08:43 perf.data [root@localhost ~]# 当前机器172.16.11.148机器上运行的docker容器： [root@localhost ~]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 29a2ad2386f7 feisky/php-fpm:sp "php-fpm -F --pid ..." 2 days ago Up 2 days phpfpm 5fffa93ef2cd feisky/nginx:sp "nginx -g 'daemon ..." 2 days ago Up 2 days 0.0.0.0:10000->80/tcp nginx [root@localhost ~]# cp perf.data到容器里： [root@localhost ~]# docker cp perf.data phpfpm:/tmp [root@localhost ~]# 进入docker容器： [root@localhost ~]# docker exec -i -t phpfpm bash root@5fffa93ef2cd:/app# hostname 5fffa93ef2cd root@5fffa93ef2cd:/app# root@5fffa93ef2cd:/app# cat /etc/issue Debian GNU/Linux 9 \n \l root@5fffa93ef2cd:/app# cat /etc/hosts 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters 172.17.0.2 5fffa93ef2cd root@5fffa93ef2cd:/app# cd /tmp 更新apt-get软件包，并安装性能分析工具包： root@5fffa93ef2cd:/tmp# apt-get update Get:1 http://security.debian.org stretch/updates InRelease [53.0 kB] Ign:2 http://httpredir.debian.org/debian stretch InRelease Get:3 http://httpredir.debian.org/debian stretch Release [118 kB] Get:4 http://httpredir.debian.org/debian stretch Release.gpg [3177 B] Get:5 http://security.debian.org stretch/updates/main amd64 Packages [909 kB] Get:6 http://httpredir.debian.org/debian stretch/main amd64 Packages [9610 kB] Fetched 10.7 MB in 4s (2577 kB/s) Reading package lists... Done root@5fffa93ef2cd:/tmp# apt-get install -y linux-perf linux-tools procps Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: ... ... Setting up linux-tools (4.9+80+deb9u14) ... Processing triggers for libc-bin (2.24-11+deb9u3) ... root@5fffa93ef2cd:/tmp# 执行分析： root@5fffa93ef2cd:/tmp# perf_4.9 report report Read perf.data (created by perf record) and display the profile sched Tool to trace/measure scheduler properties (latencies) script Read perf.data (created by perf record) and display trace output Samples: 130K of event 'cycles', Event count (approx.): 96230260054 Children Self Command Shared Object Symbol + 73.71% 0.02% stress stress [.] main + 30.12% 26.88% stress stress [.] hoghdd + 19.81% 19.57% stress libc-2.24.so [.] random_r + 17.45% 17.27% stress libc-2.24.so [.] random + 4.04% 0.00% stress [kernel.kallsyms] [k] 0xffffffffb9716768 + 4.01% 0.00% stress [kernel.kallsyms] [k] 0xffffffffb971a925 + 3.89% 3.83% stress libc-2.24.so [.] rand + 3.76% 0.00% stress [kernel.kallsyms] [k] 0xffffffffb971a597 + 3.73% 0.01% php-fpm libc-2.24.so [.] _IO_proc_open + 3.36% 0.00% stress [kernel.kallsyms] [k] 0xffffffffb91c747d + 3.21% 0.02% php-fpm libc-2.24.so [.] __libc_fork + 3.09% 0.00% php-fpm libc-2.24.so [.] execve + 3.09% 0.00% php-fpm [kernel.kallsyms] [k] 0xffffffffb971fd58 + 3.08% 0.00% php-fpm [kernel.kallsyms] [k] 0xffffffffb9223ba9 + 3.02% 0.00% php-fpm [kernel.kallsyms] [k] 0xffffffffb971fb94 + 3.02% 0.00% php-fpm [kernel.kallsyms] [k] 0xffffffffb9090a76 + 2.99% 0.00% php-fpm [kernel.kallsyms] [k] 0xffffffffb9090761 + 2.89% 0.00% php-fpm [kernel.kallsyms] [k] 0xffffffffb922380b + 2.88% 0.00% php-fpm [kernel.kallsyms] [k] 0xffffffffb908ffc2 + 2.88% 0.00% php-fpm [kernel.kallsyms] [k] 0xffffffffb922202f + 2.82% 0.00% php-fpm [kernel.kallsyms] [k] 0xffffffffb927e44c + 2.80% 0.00% php-fpm [kernel.kallsyms] [k] 0xffffffffb9222a90 + 2.80% 0.00% php-fpm [kernel.kallsyms] [k] 0xffffffffb908e0f7 + 2.48% 0.00% php-fpm libc-2.24.so [.] __libc_start_main + 2.48% 0.00% php-fpm [unknown] [k] 0x6cb6258d4c544155 + 2.19% 0.00% stress [kernel.kallsyms] [k] 0xffffffffb971fa51 + 1.92% 0.00% stress [kernel.kallsyms] [k] 0xffffffffb919e157
看到有stress进程占用了大量CPU资源。
四 问题小结
该案例中，系统CPU资源使用率非常高，但是却找不到消耗CPU资源的进程的场景。着实比较恼人，但是我们也有对应的分析思路。
如果CPU使用率高，又找不到消耗CPU的进程。我们应该联想到，可能是短时应用带来的问题：
应用系统/程序里直接调用了其它二进制或者是可执行程序，这些被调用的程序运行时间非常短，且频繁的运行，这时通过top等工具无法捕捉到消耗CPU资源的进程；
这时，我们可以借助pstree或者execsnoop工具，找到进程的父进程，通过父进程进一步排查。
碰到常规情形下，明明CPU使用率很高却找不到是哪些进程占用了CPU资源时，通常是由于下面2种情形：
1 某些应用程序里直接调用了其它可执行的二进制程序，并且这些被调用程序执行时间非常短，转瞬即逝的就执行完了，通过top/ps等工具根本看不到或者很难看到这些进程在执行；本案例就是这种情况。
2 某些应用程序自己在不停的崩溃重启，进程启动过程里初始化资源时，可能会占用了很多的CPU资源。
五 补充
针对短时进程(short lived process)，我们也可以使用Brendan Gregg开发的execsnoop工具来分析。
5.1 execsnoop作用
从名称上可以看出exec表示execution ，snoop窥探，窥视的意思。用于监控、窥探可执行程序的工具。
5.2 execsnoop官网
可以从Brendan Gregg的GitHub仓库：
https://github.com/brendangregg/perf-tools/blob/master/execsnoop
5.3 安装和使用
本地机器touch 1个名为execsnoop的文件，其内容为直接拷贝、粘贴上述仓库地址中该文件的代码。然后，修改文件的可执行权限即可。
使用的时候，直接./execsnoop就可以了。
使用帮助，./execsnoop -h
5.4 使用execsnoop来分析本案例
[root@guoxin7 ~]# ./execsnoop Tracing exec()s. Ctrl-C to end. Instrumenting sys_execve PID PPID ARGS 16367 16365 cat -v trace_pipe ... 16854 16852 /usr/local/bin/stress -t 1 -d 1 16853 16851 /usr/local/bin/stress -t 1 -d 1 16855 27487 sh-16855 [002] d... 18225460.690274: execsnoop_sys_execve: (SyS_execve+0x0/0x30) 16850 16849 /usr/local/bin/stress -t 1 -d 1 16859 16855 /usr/local/bin/stress -t 1 -d 1 16861 27515 sh-16861 [003] d... 18225460.693129: execsnoop_sys_execve: (SyS_execve+0x0/0x30) 16862 16861 /usr/local/bin/stress -t 1 -d 1 16865 27492 sh-16865 [002] d... 18225460.710012: execsnoop_sys_execve: (SyS_execve+0x0/0x30) 16864 27499 php-fpm-16864 [002] d... 18225460.710384: execsnoop_sys_execve: (SyS_execve+0x0/0x30) 16866 16865 /usr/local/bin/stress -t 1 -d 1 16868 27504 sh-16868 [002] d... 18225460.712300: execsnoop_sys_execve: (SyS_execve+0x0/0x30) 16870 16868 /usr/local/bin/stress -t 1 -d 1 16869 16864 /usr/local/bin/stress -t 1 -d 1 16873 27487 sh-16873 [001] d... 18225460.716239: execsnoop_sys_execve: (SyS_execve+0x0/0x30) 16874 16873 /usr/local/bin/stress -t 1 -d 1 ....
可以看到，系统中有非常多的short lived process。
六 参考链接
https://www.brendangregg.com/blog/2014-07-28/execsnoop-for-linux.html
案例源于倪朋飞老师的《Linux 性能优化实战》付费课程06 | 案例篇：系统的 CPU 使用率很高，但为啥却找不到高 CPU 的应用？
