3 当某个应用的CPU使用达到100%，该怎么办？
??? 你最常用什么指標來描述系統的 CPU 性能呢？我想你的答案，可能不是平均負載，也不是 CPU 上下文切換，而是另一個更直觀的指標—— CPU 使用率。CPU 使用率是單位時間內 CPU 使用情況的統計，以百分比的方式展示。那么，作為最常用也是最熟悉的 CPU 指標，你能說出 CPU 使用率到底是怎么算出來的嗎？再有，諸如 top、ps 之類的性能工具展示的 %user、%nice、 %system、%iowait、%steal 等等，你又能弄清楚它們之間的不同嗎？
CPU 使用率
??? Linux 作為一個多任務操作系統，將每個 CPU 的時間劃分為很短的時間片，再通過調度器輪流分配給各個任務使用，因此造成多任務同時運行的錯覺。為了維護CPU時間，Linux通過事先定義的節拍率(內核中表示為 HZ)，觸發時間中斷，并使用全局變量 Jiffies 記錄了開機以來的節拍數。每發生一次時間中斷，Jiffies 的值就加 1。節拍率 HZ 是內核的可配選項，可以設置為 100、250、1000 等。不同的系統可能設置不同數值，你可以通過查詢 /boot/config 內核選項來查看它的配置值。比如在我的系統中，節拍率設置成了 250，也就是每秒鐘觸發 250 次時間中斷。
[root@web-01 ~]# grep 'CONFIG_HZ=' /boot/config-$(uname -r) CONFIG_HZ=1000??? 同時，正因為節拍率 HZ 是內核選項，所以用戶空間程序并不能直接訪問。為了方便用戶空間程序，內核還提供了一個用戶空間節拍率 USER_HZ，它總是固定為 100，也就是1/100 秒。這樣，用戶空間程序并不需要關心內核中 HZ 被設置成了多少，因為它看到的總是固定值 USER_HZ。
???? Linux 通過 /proc 虛擬文件系統，向用戶空間提供了系統內部狀態的信息，而 /proc/stat 提供的就是系統的 CPU 和任務統計信息。比方說，如果你只關注 CPU 的話，可以執行下面的命令：
???? 這里的輸出結果是一個表格。其中，第一列表示的是 CPU 編號，如 cpu0、cpu1 ，而第一行沒有編號的 cpu ，表示的是所有 CPU 的累加。其他列則表示不同場景下 CPU 的累加節拍數，它的單位是 USER_HZ，也就是 10 ms(1/100 秒)，所以這其實就是不同場景下的 CPU 時間。當然，這里每一列的順序并不需要你背下來。你只要記住，有需要的時候，查詢? man proc 就可以。不過，你要清楚 man proc 文檔里每一列的涵義，它們都是 CPU 使用率相關的重要指標，你還會在很多其他的性能工具中看到它們。下面，我來依次解讀一下。
user(通常縮寫為 us)，代表用戶態 CPU 時間。注意，它不包括下面的 nice 時間，但包括了 guest 時間。 nice(通常縮寫為 ni)，代表低優先級用戶態 CPU 時間，也就是進程的 nice 值被調整為 1-19 之間時的 CPU 時間。這里注意，nice 可取值范圍是 -20 到 19，數值越大，優先級反而越低。 system(通常縮寫為 sys)，代表內核態 CPU 時間。 idle(通常縮寫為 id)，代表空閑時間。注意，它不包括等待 I/O 的時間(iowait)。iowait(通常縮寫為 wa)，代表等待 I/O 的 CPU 時間。 irq(通常縮寫為 hi)，代表處理硬中斷的 CPU 時間。softirq(通常縮寫為 si)，代表處理軟中斷的 CPU 時間。 steal(通常縮寫為 st)，代表當系統運行在虛擬機中的時候，被其他虛擬機占用的CPU 時間。 guest(通常縮寫為 guest)，代表通過虛擬化運行其他操作系統的時間，也就是運行虛擬機的 CPU 時間。 guest_nice(通常縮寫為 gnice)，代表以低優先級運行虛擬機的時間。而我們通常所說的 CPU 使用率，就是除了空閑時間外的其他時間占總 CPU 時間的百分比，用公式來表示就是：
??? 根據這個公式，我們就可以從 /proc/stat 中的數據，很容易地計算出 CPU 使用率。當然，也可以用每一個場景的 CPU 時間，除以總的 CPU 時間，計算出每個場景的 CPU 使用率。
??? 不過先不要著急計算，你能說出，直接用 /proc/stat 的數據，算的是什么時間段的 CPU 使用率嗎？ 這是開機以來的節拍數累加值，所以直接算出來的，是開機以來的平均 CPU 使用率，一般沒啥參考價值。事實上，為了計算 CPU 使用率，性能工具一般都會取間隔一段時間(比如 3 秒)的兩次值，作差后，再計算出這段時間內的平均 CPU 使用率，即
??? 這個公式，就是我們用各種性能工具所看到的 CPU 使用率的實際計算方法。現在，我們知道了系統 CPU 使用率的計算方法，那進程的呢？跟系統的指標類似，Linux 也給每個進程提供了運行情況的統計信息，也就是? /proc/[pid]/stat。不過，這個文件包含的數據就比較豐富了，總共有 52 列的數據。當然，不用擔心，因為你并不需要掌握每一列的含義。還是那句話，需要的時候，查 man proc 就行。???
???? 是不是說要查看 CPU 使用率，就必須先讀取 /proc/stat 和 /proc/[pid]/stat 這兩個文件，然后再按照上面的公式計算出來呢？當然不是，各種各樣的性能分析工具已經幫我們計算好了。不過要注意的是，性能分析工具給出的都是間隔一段時間的平均 CPU 使用率，所以要注意間隔時間的設置，特別是用多個工具對比分析時，你一定要保證它們用的是相同的間隔時間。比如，對比一下 top 和 ps 這兩個工具報告的 CPU 使用率，默認的結果很可能不一樣，因為 top 默認使用 3 秒時間間隔，而 ps 使用的卻是進程的整個生命周期。
怎么查看 CPU 使用率
??? 知道了 CPU 使用率的含義后，我們再來看看要怎么查看 CPU 使用率。說到查看 CPU 使用率的工具，我猜你第一反應肯定是 top 和 ps。的確，top 和 ps 是最常用的性能分析工具：top 顯示了系統總體的 CPU 和內存使用情況，以及各個進程的資源使用情況。ps 則只顯示了每個進程的資源使用情況。比如，top 的輸出格式為：
默認每 3 秒刷新一次
top - 03:49:36 up 10:42, 1 user, load average: 0.00, 0.01, 0.05 Tasks: 92 total, 2 running, 90 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 11.8 sy, 0.0 ni, 88.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 2028088 total, 1791704 free, 96856 used, 139528 buff/cache KiB Swap: 2097148 total, 2097148 free, 0 used. 1764088 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 128004 6508 4132 S 0.0 0.3 0:01.62 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 0:01.98 ksoftirqd/0 5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H 6 root 20 0 0 0 0 S 0.0 0.0 0:00.75 kworker/u256:0 7 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/0 8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh 9 root 20 0 0 0 0 R 0.0 0.0 0:01.19 rcu_sched? 這個輸出結果中，第三行 %Cpu 就是系統的 CPU 使用率，具體每一列的含義上一節都講過，只是把 CPU 時間變換成了 CPU 使用率，我就不再重復講了。不過需要注意，top 默認顯示的是所有 CPU 的平均值，這個時候你只需要按下數字 1 ，就可以切換到每個 CPU 的使用率了。??
??? 繼續往下看，空白行之后是進程的實時信息，每個進程都有一個 %CPU 列，表示進程的CPU 使用率。它是用戶態和內核態 CPU 使用率的總和，包括進程用戶空間使用的 CPU、通過系統調用執行的內核空間? CPU? 、以及在就緒隊列等待運行的? CPU。在虛擬化環境中，它還包括了運行虛擬機占用的 CPU。
??? 所以，到這里我們可以發現，top 并沒有細分進程的用戶態 CPU 和內核態 CPU。那要怎么查看每個進程的詳細情況呢？你應該還記得上一節用到的 pidstat 吧，它正是一個專門分析每個進程 CPU 使用情況的工具。比如，下面的 pidstat 命令，就間隔 1 秒展示了進程的 5 組 CPU 使用率，包括：
用戶態 CPU 使用率 (%usr)；
內核態? CPU? 使用率(%system)；
運行虛擬機 CPU 使用率(%guest)；
等待 CPU 使用率(%wait)；
以及總的 CPU 使用率(%CPU)。
最后的 Average 部分，還計算了 5 組數據的平均值。
每隔 1 秒輸出一組數據，共輸出 5 組 [root@web-01 ~]# pidstat 1 5 Linux 3.10.0-957.21.2.el7.x86_64 (web-01) 07/12/2019 _x86_64_ (2 CPU)09:01:48 AM UID PID %usr %system %guest %wait %CPU CPU Command 09:01:49 AM 0 8423 0.99 0.00 0.00 0.00 0.99 0 node 09:01:49 AM 0 9218 0.00 0.99 0.00 0.00 0.99 0 pidstat09:01:49 AM UID PID %usr %system %guest %wait %CPU CPU Command 09:01:50 AM 27 6908 0.00 1.00 0.00 0.00 1.00 0 mysqld 09:01:50 AM 0 9218 0.00 1.00 0.00 0.00 1.00 0 pidstat09:01:50 AM UID PID %usr %system %guest %wait %CPU CPU Command09:01:51 AM UID PID %usr %system %guest %wait %CPU CPU Command09:01:52 AM 0 9218 0.00 1.00 0.00 0.00 1.00 0 pidstat09:01:52 AM UID PID %usr %system %guest %wait %CPU CPU Command09:01:53 AM 0 9218 1.00 0.00 0.00 0.00 1.00 0 pidstatAverage: UID PID %usr %system %guest %wait %CPU CPU CommandAverage: 27 6908 0.00 0.20 0.00 0.00 0.20 - mysqldAverage: 0 8423 0.20 0.00 0.00 0.00 0.20 - nodeAverage: 0 9218 0.20 0.60 0.00 0.00 0.80 - pidstatCPU 使用率過高怎么辦？
???? 通過 top、ps、pidstat 等工具，你能夠輕松找到 CPU 使用率較高(比如 100% )的進程。接下來，你可能又想知道，占用 CPU 的到底是代碼里的哪個函數呢？找到它，你才能更高效、更針對性地進行優化。
??? 我猜你第一個想到的，應該是 GDB(The GNU Project Debugger)， 這個功能強大的程序調試利器。的確，GDB 在調試程序錯誤方面很強大。但是，我又要來“挑刺”了。請你記住，GDB 并不適合在性能分析的早期應用。為什么呢？因為 GDB? 調試程序的過程會中斷程序運行，這在線上環境往往是不允許的。所以，GDB 只適合用在性能分析的后期，當你找到了出問題的大致函數后，線下再借助它來進一步調試函數內部的問題。
???? 那么哪種工具適合在第一時間分析進程的 CPU 問題呢？我的推薦是 perf。perf 是 Linux 2.6.31以后內置的性能分析工具。它以性能事件采樣為基礎，不僅可以分析系統的各種事件和內核性能，還可以用來分析指定應用程序的性能問題。使用 perf 分析 CPU 性能問題，我來說兩種最常見、也是我最喜歡的用法。第一種常見用法是 perf top，類似于 top，它能夠實時顯示占用 CPU 時鐘最多的函數或者指令，因此可以用來查找熱點函數，使用界面如下所示：yum install -y perf?
perf top Samples: 591 of event 'cpu-clock', Event count (approx.): 24787480Overhead Shared Object Symbol29.40% [kernel] [k] _raw_spin_unlock_irqrestore21.50% [kernel] [k] generic_exec_single15.81% [kernel] [k] mpt_put_msg_frame8.49% [kernel] [k] e1000_xmit_frame7.05% [kernel] [k] __do_softirq2.56% [kernel] [k] ata_sff_pio_task2.03% [kernel] [k] tick_nohz_idle_enter1.57% [kernel] [k] __x2apic_send_IPI_mask1.29% libslang.so.2.2.4 [.] SLtt_smart_puts0.77% libpthread-2.17.so [.] 0x000000000000e6a1 ......輸出結果中，第一行包含三個數據，分別是采樣數(Samples)、事件類型(event)和事件總數量(Event count)。
采樣數需要我們特別注意。如果采樣數過少(比如只有十幾個)，那下面的排序和百分比就沒什么實際參考價值了。
再往下看是一個表格式樣的數據，每一行包含四列，分別是：
第一列 Overhead ，是該符號的性能事件在所有采樣中的比例，用百分比來表示。
第二列 Shared ，是該函數或指令所在的動態共享對象(Dynamic Shared Object)， 如內核、進程名、動態鏈接庫名、內核模塊名等。
第三列 Object ，是動態共享對象的類型。比如 [.] 表示用戶空間的可執行程序、或者動態鏈接庫，而 [k] 則表示內核空間。
最后一列 Symbol 是符號名，也就是函數名。當函數名未知時，用十六進制的地址來表示。
???? 接著再來看第二種常見用法，也就是 perf record 和 perf report。 perf top 雖然實時展示了系統的性能信息，但它的缺點是并不保存數據，也就無法用于離線或者后續的分析。而 perf record 則提供了保存數據的功能，保存后的數據，需要你用 perf report 解析展示。
在實際使用中，我們還經常為 perf top 和 perf record 加上 -g 參數，開啟調用關系的采樣，方便我們根據調用鏈來分析性能問題。
操作和分析
接下來，我們正式進入操作環節。首先，在第一個終端執行下面的命令來運行 Nginx 和 PHP 應用：
docker run --name nginx -p 10000:80 -itd feisky/nginx docker run --name phpfpm -itd --network container:nginx feisky/php-fpm然后，在第二個終端使用 curl 訪問 http://[VM1 的 IP]:10000，確認 Nginx 已正常啟動。你應該可以看到 It works! 的響應。
[root@web-02 ~]# curl http://10.0.0.6:10000 It works!接著，我們來測試一下這個 Nginx 服務的性能。在第二個終端運行下面的 ab 命令：
# 并發 10 個請求測試 Nginx 性能，總共測試 100 個請求 [root@web-02 ~]# ab -c 10 -n 100 http://10.0.0.6:10000/ . . . Complete requests: 100Failed requests: 0Write errors: 0Total transferred: 17200 bytesHTML transferred: 900 bytesRequests per second: 20.29 [#/sec] (mean)Time per request: 492.739 [ms] (mean)Time per request: 49.274 [ms] (mean, across all concurrent requests) Transfer rate: 3.41 [Kbytes/sec] received . . .??? 從 ab 的輸出結果我們可以看到，Nginx 能承受的每秒平均請求數只有 20.29。你一定在吐槽，這也太差了吧。那到底是哪里出了問題呢？我們用 top 和 pidstat 再來觀察下。
??? 這次，我們在第二個終端，將測試的請求總數增加到 10000。這樣當你在第一個終端使用性能分析工具時， Nginx 的壓力還是繼續。繼續在第二個終端，運行 ab 命令：
?ab -c 10 -n 10000 http://10.240.0.5:10000/?
接著，回到第一個終端運行 top 命令，并按下數字 1 ，切換到每個 CPU 的使用率：
top - 12:37:16 up 13:07, 1 user, load average: 1.31, 0.33, 0.14 Tasks: 148 total, 6 running, 142 sleeping, 0 stopped, 0 zombie%Cpu0 : 99.0 us, 0.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.7 si, 0.0 st%Cpu1 : 99.7 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 stKiB Mem : 2028112 total, 177024 free, 455488 used, 1395600 buff/cacheKiB Swap: 2097148 total, 2097148 free, 0 used. 1258424 avail MemPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND10463 bin 20 0 336684 9364 1692 R 43.9 0.5 0:05.84 php-fpm10460 bin 20 0 336684 9368 1696 R 39.5 0.5 0:06.13 php-fpm10461 bin 20 0 336684 9364 1692 R 39.5 0.5 0:05.75 php-fpm10462 bin 20 0 336684 9364 1692 R 38.2 0.5 0:07.14 php-fpm10459 bin 20 0 336684 9372 1700 R 36.9 0.5 0:05.99 php-fpm9900 101 20 0 33092 2152 776 S 1.0 0.1 0:01.70 nginx3 root 20 0 0 0 0 S 0.3 0.0 0:00.68 ksoftirqd/09538 root 20 0 520300 62624 25208 S 0.3 3.1 0:22.93 dockerd10348 root 20 0 0 0 0 S 0.3 0.0 0:00.17 kworker/0:010464 root 20 0 162012 2280 1592 R 0.3 0.1 0:00.05 top1 root 20 0 128040 6600 4144 S 0.0 0.3 0:03.05 systemd2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H7 root rt 0 0 0 0 S 0.0 0.0 0:00.05 migration/0??? 這里可以看到，系統中有幾個 php-fpm 進程的 CPU 使用率加起來接近 200%；而每個CPU 的用戶使用率(us)也已經超過了 98%，接近飽和。這樣，我們就可以確認，正是用戶空間的 php-fpm 進程，導致 CPU 使用率驟升。
# -g 開啟調用關系分析，-p 指定 php-fpm 的進程號 21515 $ perf top -g -p 21515??? 按方向鍵切換到 php-fpm，再按下回車鍵展開 php-fpm 的調用關系，你會發現，調用關系最終到了 sqrt 和 add_function。看來，我們需要從這兩個函數入手了。
我們拷貝出 Nginx 應用的源碼，看看是不是調用了這兩個函數：
# 從容器 phpfpm 中將 PHP 源碼拷貝出來 $ docker cp phpfpm:/app .# 使用 grep 查找函數調用 $ grep sqrt -r app/ # 找到了 sqrt 調用 app/index.php: $x += sqrt($x); $ grep add_function -r app/ # 沒找到 add_function 調用，這其實是 PHP 內置函數OK，原來只有 sqrt 函數在 app/index.php 文件中調用了。那最后一步，我們就該看看這個文件的源碼了：
[root@web-01 ~]# cat app/index.php <?php // test only. $x = 0.0001;for ($i = 0; $i <= 1000000; $i++) {$x += sqrt($x);}echo "It works!"??? 呀，有沒有發現問題在哪里呢？我想你要笑話我了，居然犯了一個這么傻的錯誤，測試代碼沒刪就直接發布應用了。為了方便你驗證優化后的效果，我把修復后的應用也打包成了
一個 Docker 鏡像，你可以在第一個終端中執行下面的命令來運行它：
接著，到第二個終端來驗證一下修復后的效果。首先 Ctrl+C 停止之前的 ab 命令后，再運行下面的命令：
[root@web-02 ~]# ab -c 10 -n 10000 http://10.0.0.6:10000/...... Complete requests: 10000 Failed requests: 0 Write errors: 0 Total transferred: 1720000 bytes HTML transferred: 90000 bytes Requests per second: 1638.15 [#/sec] (mean)Time per request: 6.104 [ms] (mean)Time per request: 0.610 [ms] (mean, across all concurrent requests)Transfer rate: 275.16 [Kbytes/sec] received......??? 從這里你可以發現，現在每秒的平均請求數，已經從原來的 11 變成了 1638。你看，就是這么很傻的一個小問題，卻會極大的影響性能，并且查找起來也并不容易吧。當然，找到問題后，解決方法就簡單多了，刪除測試代碼就可以了。
小結
???? CPU 使用率是最直觀和最常用的系統性能指標，更是我們在排查性能問題時，通常會關注的第一個指標。所以我們更要熟悉它的含義，尤其要弄清楚用戶(%user)、Nice(%nice)、系統(%system) 、等待 I/O(%iowait) 、中斷(%irq)以及軟中斷(%softirq)這幾種不同 CPU 的使用率。比如說：
??? 用戶 CPU 和 Nice CPU 高，說明用戶態進程占用了較多的 CPU，所以應該著重排查進程的性能問題。
???? 系統 CPU 高，說明內核態占用了較多的 CPU，所以應該著重排查內核線程或者系統調用的性能問題。
???? I/O 等待 CPU 高，說明等待 I/O 的時間比較長，所以應該著重排查系統存儲是不是出現了 I/O 問題。
???? 軟中斷和硬中斷高，說明軟中斷或硬中斷的處理程序占用了較多的 CPU，所以應該著重排查內核中的中斷服務程序。
碰到 CPU 使用率升高的問題，你可以借助 top、pidstat 等工具，確認引發 CPU 性能問題的來源；再使用 perf 等工具，排查出引起性能問題的具體函數。
?----
執行perf top -g -p (php-fpm進程號)，發現不了sqrt函數
回復: 只看到地址而不是函數名是由于應用程序運行在容器中，它的依賴也都在容器內部， 故而perf無法找到PHP符號表。一個簡單的解決方法是使用perf record生成perf.data拷貝到容器內部 perf report。?
請問iowait time算在idle time里面嗎？cpu的利用率計算公式中空閑時間指的是idle time，還是idle+iowait time。
回復: iowait不算在idle里面?
使用perf 只能分析到16進制的地址，無法顯示函數名稱
回復: 只看到地址而不是函數名是由于應用程序運行在容器中，它的依賴也都在容器內部， 故而perf無法找到PHP符號表。
總結
以上是生活随笔為你收集整理的3 当某个应用的CPU使用达到100%，该怎么办？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 2.2 CPU 上下文切换是什么意思？（
- 下一篇： 7.12-7.19 id、w、who、l