上一節(jié)我講了 CPU 使用率是什么，并通過一個案例教你使用 top、vmstat、pidstat 等工具，排查高 CPU 使用率的進(jìn)程，然后再使用 perf top 工具，定位應(yīng)用內(nèi)部函數(shù)的問題。不過就有人留言了，說似乎感覺高 CPU 使用率的問題，還是挺容易排查的。那是不是所有 CPU 使用率高的問題，都可以這么分析呢？我想，你的答案應(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 使用率很高的時候，不一定能找到相對應(yīng)的高 CPU 使用率的進(jìn)程。今天，我就用一個 Nginx + PHP 的 Web 服務(wù)的案例，帶你來分析這種情況。

案例分析

你的準(zhǔn)備

今天依舊探究系統(tǒng) CPU 使用率高的情況，所以這次實(shí)驗(yàn)的準(zhǔn)備工作，與上節(jié)課的準(zhǔn)備工作基本相同，差別在于案例所用的 Docker 鏡像不同。本次案例還是基于 Ubuntu 18.04，同樣適用于其他的 Linux 系統(tǒng)。我使用的案例環(huán)境如下所示：

• 機(jī)器配置：2 CPU，8GB 內(nèi)存
• 預(yù)先安裝 docker、sysstat、perf、ab 等工具，如 apt install docker.io sysstat linux-tools-common apache2-utils

前面我們講到過，ab(apache bench)是一個常用的 HTTP 服務(wù)性能測試工具，這里同樣用來模擬 Nginx 的客戶端。由于 Nginx 和 PHP 的配置比較麻煩，我把它們打包成了兩個 Docker 鏡像，這樣只需要運(yùn)行兩個容器，就可以得到模擬環(huán)境。注意，這個案例要用到兩臺虛擬機(jī)，如下圖所示：你可以看到，其中一臺用作 Web 服務(wù)器，來模擬性能問題；另一臺用作 Web 服務(wù)器的客戶端，來給 Web 服務(wù)增加壓力請求。使用兩臺虛擬機(jī)是為了相互隔離，避免“交叉感染”。接下來，我們打開兩個終端，分別 SSH 登錄到兩臺機(jī)器上，并安裝上述工具。同樣注意，下面所有命令都默認(rèn)以 root 用戶運(yùn)行，如果你是用普通用戶身份登陸系統(tǒng)，請運(yùn)行 sudo su root 命令切換到 root 用戶。走到這一步，準(zhǔn)備工作就完成了。接下來，我們正式進(jìn)入操作環(huán)節(jié)。溫馨提示：案例中 PHP 應(yīng)用的核心邏輯比較簡單，你可能一眼就能看出問題，但實(shí)際生產(chǎn)環(huán)境中的源碼就復(fù)雜多了。所以，我依舊建議，操作之前別看源碼，避免先入為主，而要把它當(dāng)成一個黑盒來分析。這樣，你可以更好把握，怎么從系統(tǒng)的資源使用問題出發(fā)，分析出瓶頸所在的應(yīng)用，以及瓶頸在應(yīng)用中大概的位置。

操作和分析

首先，我們在第一個終端，執(zhí)行下面的命令運(yùn)行 Nginx 和 PHP 應(yīng)用：$ docker run --name nginx -p 10000:80 -itd feisky/nginx:sp $ docker run --name phpfpm -itd --network container:nginx feisky/php-fpm:sp然后，在第二個終端，使用 curl 訪問 http://[VM1 的 IP]:10000，確認(rèn) Nginx 已正常啟動。你應(yīng)該可以看到 It works! 的響應(yīng)。# 192.168.0.10 是第一臺虛擬機(jī)的 IP 地址 $ curl http://192.168.0.10:10000/ It works!接著，我們來測試一下這個 Nginx 服務(wù)的性能。在第二個終端運(yùn)行下面的 ab 命令。要注意，與上次操作不同的是，這次我們需要并發(fā) 100 個請求測試 Nginx 性能，總共測試 1000 個請求。# 并發(fā) 100 個請求測試 Nginx 性能，總共測試 1000 個請求 $ ab -c 100 -n 1000 http://192.168.0.10:10000/ This is ApacheBench, Version 2.3 <$Revision: 1706008 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, ... Requests per second: 87.86 [#/sec] (mean) Time per request: 1138.229 [ms] (mean) ...從 ab 的輸出結(jié)果我們可以看到，Nginx 能承受的每秒平均請求數(shù)，只有 87 多一點(diǎn)，是不是感覺它的性能有點(diǎn)差呀。那么，到底是哪里出了問題呢？我們再用 top 和 pidstat 來觀察一下。這次，我們在第二個終端，將測試的并發(fā)請求數(shù)改成 5，同時把請求時長設(shè)置為 10 分鐘(-t 600)。這樣，當(dāng)你在第一個終端使用性能分析工具時， Nginx 的壓力還是繼續(xù)的。繼續(xù)在第二個終端運(yùn)行 ab 命令：$ ab -c 5 -t 600 http://192.168.0.10:10000/然后，我們在第一個終端運(yùn)行 top 命令，觀察系統(tǒng)的 CPU 使用情況：$ top ... %Cpu(s): 80.8 us, 15.1 sy, 0.0 ni, 2.8 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 st ...PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND6882 root 20 0 8456 5052 3884 S 2.7 0.1 0:04.78 docker-containe6947 systemd+ 20 0 33104 3716 2340 S 2.7 0.0 0:04.92 nginx7494 daemon 20 0 336696 15012 7332 S 2.0 0.2 0:03.55 php-fpm7495 daemon 20 0 336696 15160 7480 S 2.0 0.2 0:03.55 php-fpm 10547 daemon 20 0 336696 16200 8520 S 2.0 0.2 0:03.13 php-fpm 10155 daemon 20 0 336696 16200 8520 S 1.7 0.2 0:03.12 php-fpm 10552 daemon 20 0 336696 16200 8520 S 1.7 0.2 0:03.12 php-fpm 15006 root 20 0 1168608 66264 37536 S 1.0 0.8 9:39.51 dockerd4323 root 20 0 0 0 0 I 0.3 0.0 0:00.87 kworker/u4:1 ...觀察 top 輸出的進(jìn)程列表可以發(fā)現(xiàn)，CPU 使用率最高的進(jìn)程也只不過才 2.7%，看起來并不高。然而，再看系統(tǒng) CPU 使用率( %Cpu )這一行，你會發(fā)現(xiàn)，系統(tǒng)的整體 CPU 使用率是比較高的：用戶 CPU 使用率(us)已經(jīng)到了 80%，系統(tǒng) CPU 為 15.1%，而空閑 CPU (id)則只有 2.8%。為什么用戶 CPU 使用率這么高呢？我們再重新分析一下進(jìn)程列表，看看有沒有可疑進(jìn)程：

• docker-containerd 進(jìn)程是用來運(yùn)行容器的，2.7% 的 CPU 使用率看起來正常；
• Nginx 和 php-fpm 是運(yùn)行 Web 服務(wù)的，它們會占用一些 CPU 也不意外，并且 2% 的 CPU 使用率也不算高；
• 再往下看，后面的進(jìn)程呢，只有 0.3% 的 CPU 使用率，看起來不太像會導(dǎo)致用戶 CPU 使用率達(dá)到 80%。

那就奇怪了，明明用戶 CPU 使用率都 80% 了，可我們挨個分析了一遍進(jìn)程列表，還是找不到高 CPU 使用率的進(jìn)程?？磥?top 是不管用了，那還有其他工具可以查看進(jìn)程 CPU 使用情況嗎？不知道你記不記得我們的老朋友 pidstat，它可以用來分析進(jìn)程的 CPU 使用情況。接下來，我們還是在第一個終端，運(yùn)行 pidstat 命令：# 間隔 1 秒輸出一組數(shù)據(jù)(按 Ctrl+C 結(jié)束) $ pidstat 1 ... 04:36:24 UID PID %usr %system %guest %wait %CPU CPU Command 04:36:25 0 6882 1.00 3.00 0.00 0.00 4.00 0 docker-containe 04:36:25 101 6947 1.00 2.00 0.00 1.00 3.00 1 nginx 04:36:25 1 14834 1.00 1.00 0.00 1.00 2.00 0 php-fpm 04:36:25 1 14835 1.00 1.00 0.00 1.00 2.00 0 php-fpm 04:36:25 1 14845 0.00 2.00 0.00 2.00 2.00 1 php-fpm 04:36:25 1 14855 0.00 1.00 0.00 1.00 1.00 1 php-fpm 04:36:25 1 14857 1.00 2.00 0.00 1.00 3.00 0 php-fpm 04:36:25 0 15006 0.00 1.00 0.00 0.00 1.00 0 dockerd 04:36:25 0 15801 0.00 1.00 0.00 0.00 1.00 1 pidstat 04:36:25 1 17084 1.00 0.00 0.00 2.00 1.00 0 stress 04:36:25 0 31116 0.00 1.00 0.00 0.00 1.00 0 atopacctd ...觀察一會兒，你是不是發(fā)現(xiàn)，所有進(jìn)程的 CPU 使用率也都不高啊，最高的 Docker 和 Nginx 也只有 4% 和 3%，即使所有進(jìn)程的 CPU 使用率都加起來，也不過是 21%，離 80% 還差得遠(yuǎn)呢！最早的時候，我碰到這種問題就完全懵了：明明用戶 CPU 使用率已經(jīng)高達(dá) 80%，但我卻怎么都找不到是哪個進(jìn)程的問題。到這里，你也可以想想，你是不是也遇到過這種情況？還能不能再做進(jìn)一步的分析呢？后來我發(fā)現(xiàn)，會出現(xiàn)這種情況，很可能是因?yàn)榍懊娴姆治雎┝艘恍╆P(guān)鍵信息。你可以先暫停一下，自己往上翻，重新操作檢查一遍?；蛘?#xff0c;我們一起返回去分析 top 的輸出，看看能不能有新發(fā)現(xiàn)?，F(xiàn)在，我們回到第一個終端，重新運(yùn)行 top 命令，并觀察一會兒：$ top top - 04:58:24 up 14 days, 15:47, 1 user, load average: 3.39, 3.82, 2.74 Tasks: 149 total, 6 running, 93 sleeping, 0 stopped, 0 zombie %Cpu(s): 77.7 us, 19.3 sy, 0.0 ni, 2.0 id, 0.0 wa, 0.0 hi, 1.0 si, 0.0 st KiB Mem : 8169348 total, 2543916 free, 457976 used, 5167456 buff/cache KiB Swap: 0 total, 0 free, 0 used. 7363908 avail MemPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND6947 systemd+ 20 0 33104 3764 2340 S 4.0 0.0 0:32.69 nginx6882 root 20 0 12108 8360 3884 S 2.0 0.1 0:31.40 docker-containe 15465 daemon 20 0 336696 15256 7576 S 2.0 0.2 0:00.62 php-fpm 15466 daemon 20 0 336696 15196 7516 S 2.0 0.2 0:00.62 php-fpm 15489 daemon 20 0 336696 16200 8520 S 2.0 0.2 0:00.62 php-fpm6948 systemd+ 20 0 33104 3764 2340 S 1.0 0.0 0:00.95 nginx 15006 root 20 0 1168608 65632 37536 S 1.0 0.8 9:51.09 dockerd 15476 daemon 20 0 336696 16200 8520 S 1.0 0.2 0:00.61 php-fpm 15477 daemon 20 0 336696 16200 8520 S 1.0 0.2 0:00.61 php-fpm 24340 daemon 20 0 8184 1616 536 R 1.0 0.0 0:00.01 stress 24342 daemon 20 0 8196 1580 492 R 1.0 0.0 0:00.01 stress 24344 daemon 20 0 8188 1056 492 R 1.0 0.0 0:00.01 stress 24347 daemon 20 0 8184 1356 540 R 1.0 0.0 0:00.01 stress ...這次從頭開始看 top 的每行輸出，咦？Tasks 這一行看起來有點(diǎn)奇怪，就緒隊列中居然有 6 個 Running 狀態(tài)的進(jìn)程(6 running)，是不是有點(diǎn)多呢？回想一下 ab 測試的參數(shù)，并發(fā)請求數(shù)是 5。再看進(jìn)程列表里， php-fpm 的數(shù)量也是 5，再加上 Nginx，好像同時有 6 個進(jìn)程也并不奇怪。但真的是這樣嗎？再仔細(xì)看進(jìn)程列表，這次主要看 Running(R) 狀態(tài)的進(jìn)程。你有沒有發(fā)現(xiàn)， Nginx 和所有的 php-fpm 都處于 Sleep(S)狀態(tài)，而真正處于 Running(R)狀態(tài)的，卻是幾個 stress 進(jìn)程。這幾個 stress 進(jìn)程就比較奇怪了，需要我們做進(jìn)一步的分析。我們還是使用 pidstat 來分析這幾個進(jìn)程，并且使用 -p 選項指定進(jìn)程的 PID。首先，從上面 top 的結(jié)果中，找到這幾個進(jìn)程的 PID。比如，先隨便找一個 24344，然后用 pidstat 命令看一下它的 CPU 使用情況：$ pidstat -p 2434416:14:55 UID PID %usr %system %guest %wait %CPU CPU Command奇怪，居然沒有任何輸出。難道是 pidstat 命令出問題了嗎？之前我說過，在懷疑性能工具出問題前，最好還是先用其他工具交叉確認(rèn)一下。那用什么工具呢？ ps 應(yīng)該是最簡單易用的。我們在終端里運(yùn)行下面的命令，看看 24344 進(jìn)程的狀態(tài)：# 從所有進(jìn)程中查找 PID 是 24344 的進(jìn)程 $ ps aux | grep 24344 root 9628 0.0 0.0 14856 1096 pts/0 S+ 16:15 0:00 grep --color=auto 24344還是沒有輸出?，F(xiàn)在終于發(fā)現(xiàn)問題，原來這個進(jìn)程已經(jīng)不存在了，所以 pidstat 就沒有任何輸出。既然進(jìn)程都沒了，那性能問題應(yīng)該也跟著沒了吧。我們再用 top 命令確認(rèn)一下：$ top ... %Cpu(s): 80.9 us, 14.9 sy, 0.0 ni, 2.8 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 st ...PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND6882 root 20 0 12108 8360 3884 S 2.7 0.1 0:45.63 docker-containe6947 systemd+ 20 0 33104 3764 2340 R 2.7 0.0 0:47.79 nginx3865 daemon 20 0 336696 15056 7376 S 2.0 0.2 0:00.15 php-fpm6779 daemon 20 0 8184 1112 556 R 0.3 0.0 0:00.01 stress ...好像又錯了。結(jié)果還跟原來一樣，用戶 CPU 使用率還是高達(dá) 80.9%，系統(tǒng) CPU 接近 15%，而空閑 CPU 只有 2.8%，Running 狀態(tài)的進(jìn)程有 Nginx、stress 等?？墒?#xff0c;剛剛我們看到 stress 進(jìn)程不存在了，怎么現(xiàn)在還在運(yùn)行呢？再細(xì)看一下 top 的輸出，原來，這次 stress 進(jìn)程的 PID 跟前面不一樣了，原來的 PID 24344 不見了，現(xiàn)在的是 6779。進(jìn)程的 PID 在變，這說明什么呢？在我看來，要么是這些進(jìn)程在不停地重啟，要么就是全新的進(jìn)程，這無非也就兩個原因：

• 第一個原因，進(jìn)程在不停地崩潰重啟，比如因?yàn)槎五e誤、配置錯誤等等，這時，進(jìn)程在退出后可能又被監(jiān)控系統(tǒng)自動重啟了。
• 第二個原因，這些進(jìn)程都是短時進(jìn)程，也就是在其他應(yīng)用內(nèi)部通過 exec 調(diào)用的外面命令。這些命令一般都只運(yùn)行很短的時間就會結(jié)束，你很難用 top 這種間隔時間比較長的工具發(fā)現(xiàn)(上面的案例，我們碰巧發(fā)現(xiàn)了)。

至于 stress，我們前面提到過，它是一個常用的壓力測試工具。它的 PID 在不斷變化中，看起來像是被其他進(jìn)程調(diào)用的短時進(jìn)程。要想繼續(xù)分析下去，還得找到它們的父進(jìn)程。要怎么查找一個進(jìn)程的父進(jìn)程呢？沒錯，用 pstree 就可以用樹狀形式顯示所有進(jìn)程之間的關(guān)系：$ pstree | grep stress|-docker-containe-+-php-fpm-+-php-fpm---sh---stress| |-3*[php-fpm---sh---stress---stress]從這里可以看到，stress 是被 php-fpm 調(diào)用的子進(jìn)程，并且進(jìn)程數(shù)量不止一個(這里是 3 個)。找到父進(jìn)程后，我們能進(jìn)入 app 的內(nèi)部分析了。首先，當(dāng)然應(yīng)該去看看它的源碼。運(yùn)行下面的命令，把案例應(yīng)用的源碼拷貝到 app 目錄，然后再執(zhí)行 grep 查找是不是有代碼再調(diào)用 stress 命令：# 拷貝源碼到本地 $ docker cp phpfpm:/app .# grep 查找看看是不是有代碼在調(diào)用 stress 命令 $ 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 命令。再來看看 app/index.php 的源代碼：$ 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!"; } ?>可以看到，源碼里對每個請求都會調(diào)用一個 stress 命令，模擬 I/O 壓力。從注釋上看，stress 會通過 write() 和 unlink() 對 I/O 進(jìn)程進(jìn)行壓測，看來，這應(yīng)該就是系統(tǒng) CPU 使用率升高的根源了。不過，stress 模擬的是 I/O 壓力，而之前在 top 的輸出中看到的，卻一直是用戶 CPU 和系統(tǒng) CPU 升高，并沒見到 iowait 升高。這又是怎么回事呢？stress 到底是不是 CPU 使用率升高的原因呢？我們還得繼續(xù)往下走。從代碼中可以看到，給請求加入 verbose=1 參數(shù)后，就可以查看 stress 的輸出。你先試試看，在第二個終端運(yùn)行：$ curl http://192.168.0.10:10000?verbose=1 Server internal error: Array ([0] => stress: info: [19607] dispatching hogs: 0 cpu, 0 io, 0 vm, 1 hdd[1] => stress: FAIL: [19608] (563) mkstemp failed: Permission denied[2] => stress: FAIL: [19607] (394) <-- worker 19608 returned error 1[3] => stress: WARN: [19607] (396) now reaping child worker processes[4] => stress: FAIL: [19607] (400) kill error: No such process[5] => stress: FAIL: [19607] (451) failed run completed in 0s )看錯誤消息 mkstemp failed: Permission denied ，以及 failed run completed in 0s。原來 stress 命令并沒有成功，它因?yàn)闄?quán)限問題失敗退出了?？磥?#xff0c;我們發(fā)現(xiàn)了一個 PHP 調(diào)用外部 stress 命令的 bug：沒有權(quán)限創(chuàng)建臨時文件。從這里我們可以猜測，正是由于權(quán)限錯誤，大量的 stress 進(jìn)程在啟動時初始化失敗，進(jìn)而導(dǎo)致用戶 CPU 使用率的升高。分析出問題來源，下一步是不是就要開始優(yōu)化了呢？當(dāng)然不是！既然只是猜測，那就需要再確認(rèn)一下，這個猜測到底對不對，是不是真的有大量的 stress 進(jìn)程。該用什么工具或指標(biāo)呢？我們前面已經(jīng)用了 top、pidstat、pstree 等工具，沒有發(fā)現(xiàn)大量的 stress 進(jìn)程。那么，還有什么其他的工具可以用嗎？還記得上一期提到的 perf 嗎？它可以用來分析 CPU 性能事件，用在這里就很合適。依舊在第一個終端中運(yùn)行 perf record -g 命令 ，并等待一會兒(比如 15 秒)后按 Ctrl+C 退出。然后再運(yùn)行 perf report 查看報告：# 記錄性能事件，等待大約 15 秒后按 Ctrl+C 退出 $ perf record -g# 查看報告 $ perf report這樣，你就可以看到下圖這個性能報告：你看，stress 占了所有 CPU 時鐘事件的 77%，而 stress 調(diào)用調(diào)用棧中比例最高的，是隨機(jī)數(shù)生成函數(shù) random()，看來它的確就是 CPU 使用率升高的元兇了。隨后的優(yōu)化就很簡單了，只要修復(fù)權(quán)限問題，并減少或刪除 stress 的調(diào)用，就可以減輕系統(tǒng)的 CPU 壓力。當(dāng)然，實(shí)際生產(chǎn)環(huán)境中的問題一般都要比這個案例復(fù)雜，在你找到觸發(fā)瓶頸的命令行后，卻可能發(fā)現(xiàn)，這個外部命令的調(diào)用過程是應(yīng)用核心邏輯的一部分，并不能輕易減少或者刪除。這時，你就得繼續(xù)排查，為什么被調(diào)用的命令，會導(dǎo)致 CPU 使用率升高或 I/O 升高等問題。這些復(fù)雜場景的案例，我會在后面的綜合實(shí)戰(zhàn)里詳細(xì)分析。最后，在案例結(jié)束時，不要忘了清理環(huán)境，執(zhí)行下面的 Docker 命令，停止案例中用到的 Nginx 進(jìn)程：$ docker rm -f nginx phpfpm

execsnoop

在這個案例中，我們使用了 top、pidstat、pstree 等工具分析了系統(tǒng) CPU 使用率高的問題，并發(fā)現(xiàn) CPU 升高是短時進(jìn)程 stress 導(dǎo)致的，但是整個分析過程還是比較復(fù)雜的。對于這類問題，有沒有更好的方法監(jiān)控呢？execsnoop 就是一個專為短時進(jìn)程設(shè)計的工具。它通過 ftrace 實(shí)時監(jiān)控進(jìn)程的 exec() 行為，并輸出短時進(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)程在不停啟動：# 按 Ctrl+C 結(jié)束 $ execsnoop PCOMM PID PPID RET ARGS sh 30394 30393 0 stress 30396 30394 0 /usr/local/bin/stress -t 1 -d 1 sh 30398 30393 0 stress 30399 30398 0 /usr/local/bin/stress -t 1 -d 1 sh 30402 30400 0 stress 30403 30402 0 /usr/local/bin/stress -t 1 -d 1 sh 30405 30393 0 stress 30407 30405 0 /usr/local/bin/stress -t 1 -d 1 ...execsnoop 所用的 ftrace 是一種常用的動態(tài)追蹤技術(shù)，一般用于分析 Linux 內(nèi)核的運(yùn)行時行為，后面課程我也會詳細(xì)介紹并帶你使用。

小結(jié)

碰到常規(guī)問題無法解釋的 CPU 使用率情況時，首先要想到有可能是短時應(yīng)用導(dǎo)致的問題，比如有可能是下面這兩種情況。第一，應(yīng)用里直接調(diào)用了其他二進(jìn)制程序，這些程序通常運(yùn)行時間比較短，通過 top 等工具也不容易發(fā)現(xiàn)。第二，應(yīng)用本身在不停地崩潰重啟，而啟動過程的資源初始化，很可能會占用相當(dāng)多的 CPU。對于這類進(jìn)程，我們可以用 pstree 或者 execsnoop 找到它們的父進(jìn)程，再從父進(jìn)程所在的應(yīng)用入手，排查問題的根源。perf record -ag -- sleep 2;perf report一部到位

總結(jié)

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

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