當前位置：首頁 > 运维知识 > windows >内容正文

windows

10 | 案例篇：系统的软中断CPU使用率升高，我该怎么办？

發布時間：2024/9/3 windows 59 豆豆

生活随笔收集整理的這篇文章主要介紹了 10 | 案例篇：系统的软中断CPU使用率升高，我该怎么办？小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

上一期我給你講了軟中斷的基本原理，我們先來簡單復習下。中斷是一種異步的事件處理機制，用來提高系統的并發處理能力。中斷事件發生，會觸發執行中斷處理程序，而中斷處理程序被分為上半部和下半部這兩個部分。上半部對應硬中斷，用來快速處理中斷；下半部對應軟中斷，用來異步處理上半部未完成的工作。Linux 中的軟中斷包括網絡收發、定時、調度、RCU 鎖等各種類型，我們可以查看 proc 文件系統中的 /proc/softirqs ，觀察軟中斷的運行情況。在 Linux 中，每個 CPU 都對應一個軟中斷內核線程，名字是 ksoftirqd/CPU 編號。當軟中斷事件的頻率過高時，內核線程也會因為 CPU 使用率過高而導致軟中斷處理不及時，進而引發網絡收發延遲、調度緩慢等性能問題。軟中斷 CPU 使用率過高也是一種最常見的性能問題。今天，我就用最常見的反向代理服務器 Nginx 的案例，教你學會分析這種情況。

案例

你的準備接下來的案例基于 Ubuntu 18.04，也同樣適用于其他的 Linux 系統。我使用的案例環境是這樣的：機器配置：2 CPU、8 GB 內存。預先安裝 docker、sysstat、sar 、hping3、tcpdump 等工具，比如 apt-get install docker.io sysstat hping3 tcpdump這里我又用到了三個新工具，sar、 hping3 和 tcpdump，先簡單介紹一下：

sar 是一個系統活動報告工具，既可以實時查看系統的當前活動，又可以配置保存和報告歷史統計數據。
hping3 是一個可以構造 TCP/IP 協議數據包的工具，可以對系統進行安全審計、防火墻測試等。
tcpdump 是一個常用的網絡抓包工具，常用來分析各種網絡問題。

本次案例用到兩臺虛擬機，我畫了一張圖來表示它們的關系。你可以看到，其中一臺虛擬機運行 Nginx ，用來模擬待分析的 Web 服務器；而另一臺當作 Web 服務器的客戶端，用來給 Nginx 增加壓力請求。使用兩臺虛擬機的目的，是為了相互隔離，避免“交叉感染”。接下來，我們打開兩個終端，分別 SSH 登錄到兩臺機器上，并安裝上面提到的這些工具。同以前的案例一樣，下面的所有命令都默認以 root 用戶運行，如果你是用普通用戶身份登陸系統，請運行 sudo su root 命令切換到 root 用戶。如果安裝過程中有什么問題，同樣鼓勵你先自己搜索解決，解決不了的，可以在留言區向我提問。如果你以前已經安裝過了，就可以忽略這一點了。

操作和分析

安裝完成后，我們先在第一個終端，執行下面的命令運行案例，也就是一個最基本的 Nginx 應用：# 運行 Nginx 服務并對外開放 80 端口 $ docker run -itd --name=nginx -p 80:80 nginx然后，在第二個終端，使用 curl 訪問 Nginx 監聽的端口，確認 Nginx 正常啟動。假設 192.168.0.30 是 Nginx 所在虛擬機的 IP 地址，運行 curl 命令后你應該會看到下面這個輸出界面：$ curl http://192.168.0.30/ <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> ...接著，還是在第二個終端，我們運行 hping3 命令，來模擬 Nginx 的客戶端請求：# -S 參數表示設置 TCP 協議的 SYN(同步序列號)，-p 表示目的端口為 80 # -i u100 表示每隔 100 微秒發送一個網絡幀 # 注：如果你在實踐過程中現象不明顯，可以嘗試把 100 調小，比如調成 10 甚至 1 $ hping3 -S -p 80 -i u100 192.168.0.30現在我們再回到第一個終端，你應該發現了異常。是不是感覺系統響應明顯變慢了，即便只是在終端中敲幾個回車，都得很久才能得到響應？這個時候應該怎么辦呢？雖然在運行 hping3 命令時，我就已經告訴你，這是一個 SYN FLOOD 攻擊，你肯定也會想到從網絡方面入手，來分析這個問題。不過，在實際的生產環境中，沒人直接告訴你原因。所以，我希望你把 hping3 模擬 SYN FLOOD 這個操作暫時忘掉，然后重新從觀察到的問題開始，分析系統的資源使用情況，逐步找出問題的根源。那么，該從什么地方入手呢？剛才我們發現，簡單的 SHELL 命令都明顯變慢了，先看看系統的整體資源使用情況應該是個不錯的注意，比如執行下 top 看看是不是出現了 CPU 的瓶頸。我們在第一個終端運行 top 命令，看一下系統整體的資源使用情況。# top 運行后按數字 1 切換到顯示所有 CPU $ top top - 10:50:58 up 1 days, 22:10, 1 user, load average: 0.00, 0.00, 0.00 Tasks: 122 total, 1 running, 71 sleeping, 0 stopped, 0 zombie %Cpu0 : 0.0 us, 0.0 sy, 0.0 ni, 96.7 id, 0.0 wa, 0.0 hi, 3.3 si, 0.0 st %Cpu1 : 0.0 us, 0.0 sy, 0.0 ni, 95.6 id, 0.0 wa, 0.0 hi, 4.4 si, 0.0 st ...PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND7 root 20 0 0 0 0 S 0.3 0.0 0:01.64 ksoftirqd/016 root 20 0 0 0 0 S 0.3 0.0 0:01.97 ksoftirqd/12663 root 20 0 923480 28292 13996 S 0.3 0.3 4:58.66 docker-containe3699 root 20 0 0 0 0 I 0.3 0.0 0:00.13 kworker/u4:03708 root 20 0 44572 4176 3512 R 0.3 0.1 0:00.07 top1 root 20 0 225384 9136 6724 S 0.0 0.1 0:23.25 systemd2 root 20 0 0 0 0 S 0.0 0.0 0:00.03 kthreadd ...這里你有沒有發現異常的現象？我們從第一行開始，逐個看一下：平均負載全是 0，就緒隊列里面只有一個進程(1 running)。每個 CPU 的使用率都挺低，最高的 CPU1 的使用率也只有 4.4%，并不算高。再看進程列表，CPU 使用率最高的進程也只有 0.3%，還是不高呀。那為什么系統的響應變慢了呢？既然每個指標的數值都不大，那我們就再來看看，這些指標對應的更具體的含義。畢竟，哪怕是同一個指標，用在系統的不同部位和場景上，都有可能對應著不同的性能問題。仔細看 top 的輸出，兩個 CPU 的使用率雖然分別只有 3.3% 和 4.4%，但都用在了軟中斷上；而從進程列表上也可以看到，CPU 使用率最高的也是軟中斷進程 ksoftirqd。看起來，軟中斷有點可疑了。根據上一期的內容，既然軟中斷可能有問題，那你先要知道，究竟是哪類軟中斷的問題。停下來想想，上一節我們用了什么方法，來判斷軟中斷類型呢？沒錯，還是 proc 文件系統。觀察 /proc/softirqs 文件的內容，你就能知道各種軟中斷類型的次數。不過，這里的各類軟中斷次數，又是什么時間段里的次數呢？它是系統運行以來的累積中斷次數。所以我們直接查看文件內容，得到的只是累積中斷次數，對這里的問題并沒有直接參考意義。因為，這些中斷次數的變化速率才是我們需要關注的。那什么工具可以觀察命令輸出的變化情況呢？我想你應該想起來了，在前面案例中用過的 watch 命令，就可以定期運行一個命令來查看輸出；如果再加上 -d 參數，還可以高亮出變化的部分，從高亮部分我們就可以直觀看出，哪些內容變化得更快。比如，還是在第一個終端，我們運行下面的命令：$ watch -d cat /proc/softirqsCPU0 CPU1HI: 0 0TIMER: 1083906 2368646NET_TX: 53 9NET_RX: 1550643 1916776BLOCK: 0 0IRQ_POLL: 0 0TASKLET: 333637 3930SCHED: 963675 2293171HRTIMER: 0 0RCU: 1542111 1590625通過 /proc/softirqs 文件內容的變化情況，你可以發現， TIMER(定時中斷)、NET_RX(網絡接收)、SCHED(內核調度)、RCU(RCU 鎖)等這幾個軟中斷都在不停變化。其中，NET_RX，也就是網絡數據包接收軟中斷的變化速率最快。而其他幾種類型的軟中斷，是保證 Linux 調度、時鐘和臨界區保護這些正常工作所必需的，所以它們有一定的變化倒是正常的。那么接下來，我們就從網絡接收的軟中斷著手，繼續分析。既然是網絡接收的軟中斷，第一步應該就是觀察系統的網絡接收情況。這里你可能想起了很多網絡工具，不過，我推薦今天的主人公工具 sar 。sar 可以用來查看系統的網絡收發情況，還有一個好處是，不僅可以觀察網絡收發的吞吐量(BPS，每秒收發的字節數)，還可以觀察網絡收發的 PPS，即每秒收發的網絡幀數。我們在第一個終端中運行 sar 命令，并添加 -n DEV 參數顯示網絡收發的報告：# -n DEV 表示顯示網絡收發的報告，間隔 1 秒輸出一組數據 $ sar -n DEV 1 15:03:46 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 15:03:47 eth0 12607.00 6304.00 664.86 358.11 0.00 0.00 0.00 0.01 15:03:47 docker0 6302.00 12604.00 270.79 664.66 0.00 0.00 0.00 0.00 15:03:47 lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 15:03:47 veth9f6bbcd 6302.00 12604.00 356.95 664.66 0.00 0.00 0.00 0.05對于 sar 的輸出界面，我先來簡單介紹一下，從左往右依次是：

第一列：表示報告的時間。
第二列：IFACE 表示網卡。
第三、四列：rxpck/s 和 txpck/s 分別表示每秒接收、發送的網絡幀數，也就是 PPS。
第五、六列：rxkB/s 和 txkB/s 分別表示每秒接收、發送的千字節數，也就是 BPS。

后面的其他參數基本接近 0，顯然跟今天的問題沒有直接關系，你可以先忽略掉。我們具體來看輸出的內容，你可以發現：對網卡 eth0 來說，每秒接收的網絡幀數比較大，達到了 12607，而發送的網絡幀數則比較小，只有 6304；每秒接收的千字節數只有 664 KB，而發送的千字節數更小，只有 358 KB。docker0 和 veth9f6bbcd 的數據跟 eth0 基本一致，只是發送和接收相反，發送的數據較大而接收的數據較小。這是 Linux 內部網橋轉發導致的，你暫且不用深究，只要知道這是系統把 eth0 收到的包轉發給 Nginx 服務即可。具體工作原理，我會在后面的網絡部分詳細介紹。從這些數據，你有沒有發現什么異常的地方？既然懷疑是網絡接收中斷的問題，我們還是重點來看 eth0 ：接收的 PPS 比較大，達到 12607，而接收的 BPS 卻很小，只有 664 KB。直觀來看網絡幀應該都是比較小的，我們稍微計算一下，664*1024/12607 = 54 字節，說明平均每個網絡幀只有 54 字節，這顯然是很小的網絡幀，也就是我們通常所說的小包問題。那么，有沒有辦法知道這是一個什么樣的網絡幀，以及從哪里發過來的呢？使用 tcpdump 抓取 eth0 上的包就可以了。我們事先已經知道， Nginx 監聽在 80 端口，它所提供的 HTTP 服務是基于 TCP 協議的，所以我們可以指定 TCP 協議和 80 端口精確抓包。接下來，我們在第一個終端中運行 tcpdump 命令，通過 -i eth0 選項指定網卡 eth0，并通過 tcp port 80 選項指定 TCP 協議的 80 端口：# -i eth0 只抓取 eth0 網卡，-n 不解析協議名和主機名 # tcp port 80 表示只抓取 tcp 協議并且端口號為 80 的網絡幀 $ tcpdump -i eth0 -n tcp port 80 15:11:32.678966 IP 192.168.0.2.18238 > 192.168.0.30.80: Flags [S], seq 458303614, win 512, length 0 ...從 tcpdump 的輸出中，你可以發現192.168.0.2.18238 > 192.168.0.30.80 ，表示網絡幀從 192.168.0.2 的 18238 端口發送到 192.168.0.30 的 80 端口，也就是從運行 hping3 機器的 18238 端口發送網絡幀，目的為 Nginx 所在機器的 80 端口。Flags [S] 則表示這是一個 SYN 包。再加上前面用 sar 發現的， PPS 超過 12000 的現象，現在我們可以確認，這就是從 192.168.0.2 這個地址發送過來的 SYN FLOOD 攻擊。到這里，我們已經做了全套的性能診斷和分析。從系統的軟中斷使用率高這個現象出發，通過觀察 /proc/softirqs 文件的變化情況，判斷出軟中斷類型是網絡接收中斷；再通過 sar 和 tcpdump ，確認這是一個 SYN FLOOD 問題。SYN FLOOD 問題最簡單的解決方法，就是從交換機或者硬件防火墻中封掉來源 IP，這樣 SYN FLOOD 網絡幀就不會發送到服務器中。至于 SYN FLOOD 的原理和更多解決思路，你暫時不需要過多關注，后面的網絡章節里我們都會學到。案例結束后，也不要忘了收尾，記得停止最開始啟動的 Nginx 服務以及 hping3 命令。在第一個終端中，運行下面的命令就可以停止 Nginx 了：# 停止 Nginx 服務 $ docker rm -f nginx然后到第二個終端中按下 Ctrl+C 就可以停止 hping3。

小結

軟中斷 CPU 使用率(softirq)升高是一種很常見的性能問題。雖然軟中斷的類型很多，但實際生產中，我們遇到的性能瓶頸大多是網絡收發類型的軟中斷，特別是網絡接收的軟中斷。在碰到這類問題時，你可以借用 sar、tcpdump 等工具，做進一步分析。不要害怕網絡性能，后面我會教你更多的分析方法。

總結

以上是生活随笔為你收集整理的10 | 案例篇：系统的软中断CPU使用率升高，我该怎么办？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： 09 | 基础篇：怎么理解Linux软中
下一篇： 11 | 套路篇：如何迅速分析出系统CP