??? 上一節(jié)講了 CPU 使用率是什么，并通過(guò)一個(gè)案例教你使用 top、vmstat、pidstat 等工具，排查高 CPU 使用率的進(jìn)程，然后再使用 perf top 工具，定位應(yīng)用內(nèi)部函數(shù)的問(wèn)題。不過(guò)就有人留言了，說(shuō)似乎感覺(jué)高 CPU 使用率的問(wèn)題，還是挺容易排查的。那是不是所有 CPU 使用率高的問(wèn)題，都可以這么分析呢？我想，你的答案應(yīng)該是否定的。

??? 回顧前面的內(nèi)容，我們知道，系統(tǒng)的 CPU 使用率，不僅包括進(jìn)程用戶態(tài)和內(nèi)核態(tài)的運(yùn)行， 還包括中斷處理、等待 I/O 以及內(nèi)核線程等。所以，當(dāng)你發(fā)現(xiàn)系統(tǒng)的 CPU 使用率很高的 時(shí)候，不一定能找到相對(duì)應(yīng)的高 CPU 使用率的進(jìn)程。

案例分析

準(zhǔn)備

探究系統(tǒng) CPU 使用率高的情況，所以這次實(shí)驗(yàn)的準(zhǔn)備工作，與上節(jié)課的準(zhǔn)備工作基本相同，差別在于案例所用的 Docker 鏡像不同。

預(yù)先安裝 docker、sysstat、perf、ab 等工具，如 yum install docker.io sysstat linux-tools-common apache2-utils ，ab(apache bench)是一個(gè)常用的 HTTP 服務(wù)性能測(cè)試工具，這里同樣用來(lái)模擬 Nginx 的客戶端。由于 Nginx 和 PHP 的配置比較麻煩，我把它們打包成了兩個(gè) Docker 鏡像，這樣只需要運(yùn)行兩個(gè)容器，就可以得到模擬環(huán)境。

??? 其中一臺(tái)用作 Web 服務(wù)器，來(lái)模擬性能問(wèn)題；另一臺(tái)用作 Web 服務(wù)器的客戶端，來(lái)給 Web 服務(wù)增加壓力請(qǐng)求。使用兩臺(tái)虛擬機(jī)是為了相互隔離，避免“交叉感染”。

docker run --name nginx -p 10000:80 -itd feisky/nginx:sp docker run --name phpfpm -itd --network container:nginx feisky/php-fpm:sp訪問(wèn)第一臺(tái)機(jī)器 [root@bzhl ~]# curl http://23.106.155.240:10000/ It works!

測(cè)試

??? 我們來(lái)測(cè)試一下這個(gè) Nginx 服務(wù)的性能。在第二個(gè)終端運(yùn)行下面的 ab 命令。要注意，與上次操作不同的是，這次我們需要并發(fā) 100 個(gè)請(qǐng)求測(cè)試 Nginx 性能，總共測(cè)試1000 個(gè)請(qǐng)求。

[root@bzhl ~]# ab -c 100 -n 1000 http://23.106.155.240:10000/Complete requests: 1000 Failed requests: 0 Total transferred: 172000 bytes HTML transferred: 9000 bytes Requests per second: 112.08 [#/sec] (mean) Time per request: 892.222 [ms] (mean) Time per request: 8.922 [ms] (mean, across all concurrent requests) Transfer rate: 18.83 [Kbytes/sec] received

??? 從 ab 的輸出結(jié)果我們可以看到，Nginx 能承受的每秒平均請(qǐng)求數(shù)，只有 112.08多一點(diǎn)，是不是感覺(jué)它的性能有點(diǎn)差呀。那么，到底是哪里出了問(wèn)題呢？我們?cè)儆?top 和 pidstat 來(lái)觀察一下。這次，我們?cè)诘诙€(gè)終端，將測(cè)試的并發(fā)請(qǐng)求數(shù)改成 5，同時(shí)把請(qǐng)求時(shí)長(zhǎng)設(shè)置為 10 分鐘(-t 600)。這樣，當(dāng)你在第一個(gè)終端使用性能分析工具時(shí)， Nginx 的壓力還是繼續(xù)的。繼續(xù)在第二個(gè)終端運(yùn)行 ab 命令：

??? 然后，我們?cè)诘谝粋€(gè)終端運(yùn)行 top 命令，觀察系統(tǒng)的 CPU 使用情況：

top - 11:22:55 up 35 days, 21:36, 1 user, load average: 1.28, 0.52, 0.22 Tasks: 119 total, 6 running, 74 sleeping, 0 stopped, 0 zombie %Cpu0 : 60.4 us, 14.7 sy, 0.0 ni, 24.6 id, 0.0 wa, 0.0 hi, 0.4 si, 0.0 st %Cpu1 : 59.6 us, 15.7 sy, 0.0 ni, 22.3 id, 0.0 wa, 0.0 hi, 2.4 si, 0.0 st KiB Mem : 2057308 total, 152184 free, 366672 used, 1538452 buff/cache KiB Swap: 524284 total, 523760 free, 524 used. 1402364 avail MemPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 32020 101 20 0 33104 3692 2276 S 3.7 0.2 0:01.67 nginx 2743 bin 20 0 336696 16064 8392 S 2.7 0.8 0:00.95 php-fpm 2752 bin 20 0 336696 16064 8392 S 2.3 0.8 0:00.96 php-fpm 2755 bin 20 0 336696 16064 8392 S 2.3 0.8 0:00.90 php-fpm 2738 bin 20 0 336696 16064 8392 S 2.0 0.8 0:00.95 php-fpm 2766 bin 20 0 336696 16064 8392 S 2.0 0.8 0:00.91 php-fpm 31726 root 20 0 655612 77988 39920 S 1.3 3.8 0:15.71 dockerd 31970 root 20 0 108756 8400 4504 S 1.3 0.4 0:00.87 containerd-shim10 root 20 0 0 0 0 R 0.3 0.0 0:47.50 rcu_sched 6094 root 20 0 221712 20704 7596 S 0.3 1.0 32:23.52 python1 root 20 0 125520 5220 3828 S 0.0 0.3 1:40.77 systemd

??? 觀察 top 輸出的進(jìn)程列表可以發(fā)現(xiàn)，CPU 使用率最高的進(jìn)程也只不過(guò)才3.7%，看起來(lái)并不高。然而，再看系統(tǒng) CPU 使用率( %Cpu )這一行，你會(huì)發(fā)現(xiàn)，系統(tǒng)的整體 CPU 使用率是比較高的：用戶 CPU 使用率(us)已經(jīng)到了 60%，系統(tǒng) CPU 為 15.1%，而空閑 CPU(id)則只有 29%。為什么用戶 CPU 使用率這么高呢？我們?cè)僦匦路治鲆幌逻M(jìn)程列表，看看有沒(méi)有可疑進(jìn)程：

docker-containerd 進(jìn)程是用來(lái)運(yùn)行容器的，2.7% 的 CPU 使用率看起來(lái)正常；

Nginx 和 php-fpm 是運(yùn)行 Web 服務(wù)的，它們會(huì)占用一些 CPU 也不意外，并且 2% 的CPU 使用率也不算高；

??? 再往下看，后面的進(jìn)程呢，只有 0.3% 的 CPU 使用率，看起來(lái)不太像會(huì)導(dǎo)致用戶 CPU 使用率達(dá)到 80%。那就奇怪了，明明用戶 CPU 使用率都 80% 了，可我們挨個(gè)分析了一遍進(jìn)程列表，還是找不到高 CPU 使用率的進(jìn)程?？磥?lái) top 是不管用了，那還有其他工具可以查看進(jìn)程 CPU 使用情況嗎？不知道你記不記得我們的老朋友 pidstat，它可以用來(lái)分析進(jìn)程的 CPU 使用情況。

[root@doit ~]# pidstat 1 Linux 4.20.0-1.el7.elrepo.x86_64 (doit) 07/14/2019 _x86_64_ (2 CPU)11:41:56 AM UID PID %usr %system %guest %wait %CPU CPU Command 11:41:57 AM 0 16 0.00 0.97 0.00 0.00 0.97 1 ksoftirqd/1 11:41:57 AM 1 7110 0.00 0.97 0.00 3.88 0.97 1 php-fpm 11:41:57 AM 1 7115 0.97 1.94 0.00 4.85 2.91 1 php-fpm 11:41:57 AM 1 7123 0.00 1.94 0.00 2.91 1.94 0 php-fpm 11:41:57 AM 1 7127 0.00 0.97 0.00 2.91 0.97 1 php-fpm 11:41:57 AM 1 7137 0.97 1.94 0.00 4.85 2.91 0 php-fpm 11:41:57 AM 0 24569 0.00 0.97 0.00 0.00 0.97 1 pidstat 11:41:57 AM 1 24780 0.00 2.91 0.00 0.00 2.91 1 php-fpm 11:41:57 AM 0 31726 0.97 0.00 0.00 0.00 0.97 1 dockerd 11:41:57 AM 0 31970 0.00 1.94 0.00 0.00 1.94 0 containerd-shim 11:41:57 AM 101 32020 0.97 1.94 0.00 11.65 2.91 0 nginx[root@doit ~]# uptime 11:42:56 up 35 days, 21:56, 1 user, load average: 2.82, 1.33, 0.81

??? 觀察一會(huì)兒，你是不是發(fā)現(xiàn)，所有進(jìn)程的 CPU 使用率也都不高啊，最高的 Docker 和Nginx 也只有 4% 和 3%，即使所有進(jìn)程的 CPU 使用率都加起來(lái)，也不過(guò)是 21%，離80% 還差得遠(yuǎn)呢！后來(lái)我發(fā)現(xiàn)，會(huì)出現(xiàn)這種情況，很可能是因?yàn)榍懊娴姆治雎┝艘恍╆P(guān)鍵信息。你可以先暫 停一下，自己往上翻，重新操作檢查一遍。或者，我們一起返回去分析 top 的輸出，看看能不能有新發(fā)現(xiàn)?，F(xiàn)在，我們回到第一個(gè)終端，重新運(yùn)行 top 命令，并觀察一會(huì)兒

top - 11:49:53 up 35 days, 22:03, 2 users, load average: 4.12, 3.15, 1.84 Tasks: 128 total, 4 running, 82 sleeping, 0 stopped, 0 zombie %Cpu(s): 49.5 us, 12.6 sy, 0.0 ni, 36.7 id, 0.0 wa, 0.0 hi, 1.2 si, 0.0 st KiB Mem : 2057308 total, 93240 free, 374216 used, 1589852 buff/cache KiB Swap: 524284 total, 523760 free, 524 used. 1389000 avail MemPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 32020 101 20 0 33104 3692 2276 S 2.6 0.2 0:21.73 nginx 12098 bin 20 0 336696 16064 8392 S 2.0 0.8 0:06.72 php-fpm 12124 bin 20 0 336696 16064 8392 S 2.0 0.8 0:06.70 php-fpm 31970 root 20 0 108756 8220 4504 S 2.0 0.4 0:13.37 containerd-shim 12075 bin 20 0 336696 16064 8392 S 1.7 0.8 0:06.89 php-fpm 12080 bin 20 0 336696 16064 8392 S 1.7 0.8 0:06.89 php-fpm 12083 bin 20 0 336696 16064 8392 S 1.7 0.8 0:06.66 php-fpm 31726 root 20 0 655612 77920 39920 S 1.0 3.8 0:22.63 dockerd16 root 20 0 0 0 0 S 0.7 0.0 0:14.97 ksoftirqd/1 31383 bin 20 0 0 0 0 R 0.3 0.0 0:00.01 stress

??? 這次從頭開(kāi)始看 top 的每行輸出，咦？Tasks 這一行看起來(lái)有點(diǎn)奇怪，就緒隊(duì)列中居然有6 個(gè) Running 狀態(tài)的進(jìn)程(6 running)，是不是有點(diǎn)多呢？回想一下 ab 測(cè)試的參數(shù)，并發(fā)請(qǐng)求數(shù)是 5。再看進(jìn)程列表里， php-fpm 的數(shù)量也是 5， 再加上 Nginx，好像同時(shí)有 6 個(gè)進(jìn)程也并不奇怪。但真的是這樣嗎？

??? 再仔細(xì)看進(jìn)程列表，這次主要看 Running(R) 狀態(tài)的進(jìn)程。你有沒(méi)有發(fā)現(xiàn)， Nginx 和所有的 php-fpm 都處于 Sleep(S)狀態(tài)，而真正處于 Running(R)狀態(tài)的，卻是幾個(gè)stress 進(jìn)程。這幾個(gè) stress 進(jìn)程就比較奇怪了，需要我們做進(jìn)一步的分析。

我們還是使用 pidstat 來(lái)分析這幾個(gè)進(jìn)程，并且使用 -p 選項(xiàng)指定進(jìn)程的 PID。首先，從上面 top 的結(jié)果中，找到這幾個(gè)進(jìn)程的 PID。比如，先隨便找一個(gè) 24344，然后用 pidstat 命令看一下它的 CPU 使用情況：

[root@doit ~]# pidstat -p 31383 Linux 4.20.0-1.el7.elrepo.x86_64 (doit) 07/14/2019 _x86_64_ (2 CPU) 11:50:40 AM UID PID %usr %system %guest %wait %CPU CPU Command 奇怪，居然沒(méi)有任何輸出。難道是 pidstat 命令出問(wèn)題了嗎？之前我說(shuō)過(guò)，在懷疑性能工具出問(wèn)題前，最好還是先用其他工具交叉確認(rèn)一下。那用什么工具呢？ ps 應(yīng)該是最簡(jiǎn)單易用的。我們?cè)诮K端里運(yùn)行下面的命令，看看 24344 進(jìn)程的狀態(tài)：[root@doit ~]# ps aux |grep 31383 root 483 0.0 0.1 112720 2344 pts/1 S+ 11:51 0:00 grep --color=auto 31383

還是沒(méi)有輸出?，F(xiàn)在終于發(fā)現(xiàn)問(wèn)題，原來(lái)這個(gè)進(jìn)程已經(jīng)不存在了，所以 pidstat 就沒(méi)有任何輸出。既然進(jìn)程都沒(méi)了，那性能問(wèn)題應(yīng)該也跟著沒(méi)了吧。我們?cè)儆? top? 命令確認(rèn)一下：

top - 11:53:11 up 35 days, 22:06, 2 users, load average: 2.46, 2.27, 1.71 Tasks: 126 total, 6 running, 75 sleeping, 0 stopped, 2 zombie %Cpu(s): 53.8 us, 13.9 sy, 0.0 ni, 31.2 id, 0.0 wa, 0.0 hi, 1.0 si, 0.0 st KiB Mem : 2057308 total, 125672 free, 353916 used, 1577720 buff/cache KiB Swap: 524284 total, 523760 free, 524 used. 1412436 avail MemPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 32020 101 20 0 33104 3692 2276 R 2.7 0.2 0:23.15 nginx489 bin 20 0 336696 16064 8392 S 2.3 0.8 0:00.94 php-fpm484 bin 20 0 336696 16064 8392 S 2.0 0.8 0:00.88 php-fpm502 bin 20 0 336696 16064 8392 R 2.0 0.8 0:00.91 php-fpm500 bin 20 0 336696 16064 8392 S 1.7 0.8 0:00.88 php-fpm511 bin 20 0 336696 16064 8392 R 1.7 0.8 0:00.86 php-fpm 31970 root 20 0 108756 8340 4504 S 1.7 0.4 0:14.18 containerd-shim 31726 root 20 0 655612 77920 39920 S 1.0 3.8 0:23.15 dockerd10 root 20 0 0 0 0 I 0.3 0.0 0:49.25 rcu_sched 11768 bin 20 0 8188 1624 540 R 0.3 0.1 0:00.01 stress

好像又錯(cuò)了。結(jié)果還跟原來(lái)一樣，用戶 CPU 使用率還是高達(dá) 80.9%，系統(tǒng) CPU 接近15%，而空閑 CPU 只有 2.8%，Running 狀態(tài)的進(jìn)程有 Nginx、stress 等。

可是，剛剛我們看到 stress 進(jìn)程不存在了，怎么現(xiàn)在還在運(yùn)行呢？再細(xì)看一下 top 的輸出，原來(lái)，這次 stress 進(jìn)程的 PID 跟前面不一樣了，原來(lái)的 PID 24344 不見(jiàn)了，現(xiàn)在的是 6779。

進(jìn)程的 PID 在變，這說(shuō)明什么呢？在我看來(lái)，要么是這些進(jìn)程在不停地重啟，要么就是全新的進(jìn)程，這無(wú)非也就兩個(gè)原因：

第一個(gè)原因，進(jìn)程在不停地崩潰重啟，比如因?yàn)槎五e(cuò)誤、配置錯(cuò)誤等等，這時(shí)，進(jìn)程在退出后可能又被監(jiān)控系統(tǒng)自動(dòng)重啟了。

第二個(gè)原因，這些進(jìn)程都是短時(shí)進(jìn)程，也就是在其他應(yīng)用內(nèi)部通過(guò) exec 調(diào)用的外面命令。這些命令一般都只運(yùn)行很短的時(shí)間就會(huì)結(jié)束，你很難用 top 這種間隔時(shí)間比較長(zhǎng)的工具發(fā)現(xiàn)(上面的案例，我們碰巧發(fā)現(xiàn)了)。

至于 stress，我們前面提到過(guò)，它是一個(gè)常用的壓力測(cè)試工具。它的 PID 在不斷變化中， 看起來(lái)像是被其他進(jìn)程調(diào)用的短時(shí)進(jìn)程。要想繼續(xù)分析下去，還得找到它們的父進(jìn)程。

要怎么查找一個(gè)進(jìn)程的父進(jìn)程呢？沒(méi)錯(cuò)，用 pstree 就可以用樹(shù)狀形式顯示所有進(jìn)程之間的關(guān)系：

[root@doit ~]# pstree |grep stress| | | |-php-fpm---sh---stress---stress

從這里可以看到，stress 是被 php-fpm 調(diào)用的子進(jìn)程，并且進(jìn)程數(shù)量不止一個(gè)(這里是3 個(gè))。找到父進(jìn)程后，我們能進(jìn)入 app 的內(nèi)部分析了。

首先，當(dāng)然應(yīng)該去看看它的源碼。運(yùn)行下面的命令，把案例應(yīng)用的源碼拷貝到 app 目錄， 然后再執(zhí)行 grep 查找是不是有代碼再調(diào)用 stress 命令：

[root@doit ~]# docker cp phpfpm:/app . grep 查找看看是不是有代碼在調(diào)用 stress 命令[root@doit ~]# 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);

找到了，果然是 app/index.php 文件中直接調(diào)用了 stress 命令。再來(lái)看看 app/index.php 的源代碼：

[root@doit ~]# 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!"; }

可以看到，源碼里對(duì)每個(gè)請(qǐng)求都會(huì)調(diào)用一個(gè) stress 命令，模擬 I/O 壓力。從注釋上看， stress 會(huì)通過(guò) write() 和 unlink() 對(duì) I/O 進(jìn)程進(jìn)行壓測(cè)，看來(lái)，這應(yīng)該就是系統(tǒng) CPU 使用率升高的根源了。

不過(guò)，stress 模擬的是 I/O 壓力，而之前在 top 的輸出中看到的，卻一直是用戶 CPU 和系統(tǒng) CPU 升高，并沒(méi)見(jiàn)到 iowait 升高。這又是怎么回事呢？stress 到底是不是 CPU 使

用率升高的原因呢？

我們還得繼續(xù)往下走。從代碼中可以看到，給請(qǐng)求加入 verbose=1 參數(shù)后，就可以查看stress 的輸出。你先試試看，在第二個(gè)終端運(yùn)行：

[root@bzhl ~]# curl http://23.106.155.240:10000?verbose=1 Server internal error: Array ([0] => stress: info: [9490] dispatching hogs: 0 cpu, 0 io, 0 vm, 1 hdd[1] => stress: FAIL: [9491] (563) mkstemp failed: Permission denied[2] => stress: FAIL: [9490] (394) <-- worker 9491 returned error 1[3] => stress: WARN: [9490] (396) now reaping child worker processes[4] => stress: FAIL: [9490] (400) kill error: No such process[5] => stress: FAIL: [9490] (451) failed run completed in 0s )

看錯(cuò)誤消息 mkstemp failed: Permission denied ，以及 failed run completed in 0s。原來(lái) stress 命令并沒(méi)有成功，它因?yàn)闄?quán)限問(wèn)題失敗退出了。看來(lái)，我們發(fā)現(xiàn)了一個(gè) PHP 調(diào)用外部 stress 命令的 bug：沒(méi)有權(quán)限創(chuàng)建臨時(shí)文件。

從這里我們可以猜測(cè)，正是由于權(quán)限錯(cuò)誤，大量的 stress 進(jìn)程在啟動(dòng)時(shí)初始化失敗，進(jìn)而導(dǎo)致用戶 CPU 使用率的升高。

分析出問(wèn)題來(lái)源，下一步是不是就要開(kāi)始優(yōu)化了呢？當(dāng)然不是！既然只是猜測(cè)，那就需要 再確認(rèn)一下，這個(gè)猜測(cè)到底對(duì)不對(duì)，是不是真的有大量的 stress 進(jìn)程。該用什么工具或指標(biāo)呢？

我們前面已經(jīng)用了 top、pidstat、pstree 等工具，沒(méi)有發(fā)現(xiàn)大量的 stress 進(jìn)程。那么， 還有什么其他的工具可以用嗎？

還記得上一期提到的 perf 嗎？它可以用來(lái)分析 CPU 性能事件，用在這里就很合適。依舊在第一個(gè)終端中運(yùn)行 perf record -g 命令 ，并等待一會(huì)兒(比如 15 秒)后按 Ctrl+C 退出。然后再運(yùn)行 perf report 查看報(bào)告：

[root@doit ~]# perf record -g ^C[ perf record: Woken up 13 times to write data ] [ perf record: Captured and wrote 3.548 MB perf.data (25041 samples) ][root@doit ~]# perf report

　　你看，stress 占了所有 CPU 時(shí)鐘事件的 77%，而 stress 調(diào)用調(diào)用棧中比例最高的，是隨機(jī)數(shù)生成函數(shù) random()，看來(lái)它的確就是 CPU 使用率升高的元兇了。隨后的優(yōu)化就很簡(jiǎn)單了，只要修復(fù)權(quán)限問(wèn)題，并減少或刪除 stress 的調(diào)用，就可以減輕系統(tǒng)的 CPU 壓力。

　　當(dāng)然，實(shí)際生產(chǎn)環(huán)境中的問(wèn)題一般都要比這個(gè)案例復(fù)雜，在你找到觸發(fā)瓶頸的命令行后， 卻可能發(fā)現(xiàn)，這個(gè)外部命令的調(diào)用過(guò)程是應(yīng)用核心邏輯的一部分，并不能輕易減少或者刪除。這時(shí)，你就得繼續(xù)排查，為什么被調(diào)用的命令，會(huì)導(dǎo)致 CPU 使用率升高或 I/O 升高等問(wèn)題。這些復(fù)雜場(chǎng)景的案例，我會(huì)在后面的綜合實(shí)戰(zhàn)里詳細(xì)分析。最后，在案例結(jié)束時(shí)，不要忘了清理環(huán)境，執(zhí)行下面的 Docker 命令，停止案例中用到的Nginx 進(jìn)程：

?docker rm -f nginx phpfpm?

execsnoop

在這個(gè)案例中，我們使用了 top、pidstat、pstree 等工具分析了系統(tǒng) CPU 使用率高的問(wèn)題，并發(fā)現(xiàn) CPU 升高是短時(shí)進(jìn)程 stress 導(dǎo)致的，但是整個(gè)分析過(guò)程還是比較復(fù)雜的。對(duì)于這類問(wèn)題，有沒(méi)有更好的方法監(jiān)控呢？

execsnoop 就是一個(gè)專為短時(shí)進(jìn)程設(shè)計(jì)的工具。它通過(guò) ftrace 實(shí)時(shí)監(jiān)控進(jìn)程的 exec() 行為，并輸出短時(shí)進(jìn)程的基本信息，包括進(jìn)程 PID、父進(jìn)程 PID、命令行參數(shù)以及執(zhí)行的結(jié)果。

比如，用 execsnoop 監(jiān)控上述案例，就可以直接得到 stress 進(jìn)程的父進(jìn)程 PID 以及它的命令行參數(shù)，并可以發(fā)現(xiàn)大量的 stress 進(jìn)程在不停啟動(dòng)：

git clone --depth 1 https://github.com/brendangregg/perf-tools [root@doit perf-tools]# ./execsnoop

execsnoop 所用的 ftrace 是一種常用的動(dòng)態(tài)追蹤技術(shù)，一般用于分析 Linux 內(nèi)核的運(yùn)行時(shí)行為，后面課程我也會(huì)詳細(xì)介紹并帶你使用。

小結(jié)

碰到常規(guī)問(wèn)題無(wú)法解釋的 CPU 使用率情況時(shí)，首先要想到有可能是短時(shí)應(yīng)用導(dǎo)致的問(wèn)題， 比如有可能是下面這兩種情況。

　　第一，應(yīng)用里直接調(diào)用了其他二進(jìn)制程序，這些程序通常運(yùn)行時(shí)間比較短，通過(guò) top 等工具也不容易發(fā)現(xiàn)。

　　第二，應(yīng)用本身在不停地崩潰重啟，而啟動(dòng)過(guò)程的資源初始化，很可能會(huì)占用相當(dāng)多的CPU。

　　對(duì)于這類進(jìn)程，我們可以用 pstree 或者 execsnoop 找到它們的父進(jìn)程，再?gòu)母高M(jìn)程所在的應(yīng)用入手，排查問(wèn)題的根源。

perf record -ag -- sleep 2;perf report

總結(jié)

以上是生活随笔為你收集整理的4 系统的 CPU 使用率很高，但为啥却找不到高 CPU的应用？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。