10 | 案例篇：系统的软中断CPU使用率升高，我该怎么办？
生活随笔
收集整理的這篇文章主要介紹了
10 | 案例篇：系统的软中断CPU使用率升高，我该怎么办？
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
上一期我給你講了軟中斷的基本原理，我們先來簡單復習下。中斷是一種異步的事件處理機制，用來提高系統(tǒng)的并發(fā)處理能力。中斷事件發(fā)生，會觸發(fā)執(zhí)行中斷處理程序，而中斷處理程序被分為上半部和下半部這兩個部分。上半部對應(yīng)硬中斷，用來快速處理中斷；下半部對應(yīng)軟中斷，用來異步處理上半部未完成的工作。Linux 中的軟中斷包括網(wǎng)絡(luò)收發(fā)、定時、調(diào)度、RCU 鎖等各種類型，我們可以查看 proc 文件系統(tǒng)中的 /proc/softirqs ，觀察軟中斷的運行情況。在 Linux 中，每個 CPU 都對應(yīng)一個軟中斷內(nèi)核線程，名字是 ksoftirqd/CPU 編號。當軟中斷事件的頻率過高時，內(nèi)核線程也會因為 CPU 使用率過高而導致軟中斷處理不及時，進而引發(fā)網(wǎng)絡(luò)收發(fā)延遲、調(diào)度緩慢等性能問題。軟中斷 CPU 使用率過高也是一種最常見的性能問題。今天，我就用最常見的反向代理服務(wù)器 Nginx 的案例，教你學會分析這種情況。
案例
你的準備接下來的案例基于 Ubuntu 18.04，也同樣適用于其他的 Linux 系統(tǒng)。我使用的案例環(huán)境是這樣的：機器配置：2 CPU、8 GB 內(nèi)存。預先安裝 docker、sysstat、sar 、hping3、tcpdump 等工具，比如 apt-get install docker.io sysstat hping3 tcpdump這里我又用到了三個新工具，sar、 hping3 和 tcpdump，先簡單介紹一下：- sar 是一個系統(tǒng)活動報告工具，既可以實時查看系統(tǒng)的當前活動，又可以配置保存和報告歷史統(tǒng)計數(shù)據(jù)。
- hping3 是一個可以構(gòu)造 TCP/IP 協(xié)議數(shù)據(jù)包的工具，可以對系統(tǒng)進行安全審計、防火墻測試等。
- tcpdump 是一個常用的網(wǎng)絡(luò)抓包工具，常用來分析各種網(wǎng)絡(luò)問題。
操作和分析
安裝完成后，我們先在第一個終端，執(zhí)行下面的命令運行案例，也就是一個最基本的 Nginx 應(yīng)用：# 運行 Nginx 服務(wù)并對外開放 80 端口 $ docker run -itd --name=nginx -p 80:80 nginx然后，在第二個終端，使用 curl 訪問 Nginx 監(jiān)聽的端口，確認 Nginx 正常啟動。假設(shè) 192.168.0.30 是 Nginx 所在虛擬機的 IP 地址，運行 curl 命令后你應(yīng)該會看到下面這個輸出界面：$ curl http://192.168.0.30/ <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> ...接著，還是在第二個終端，我們運行 hping3 命令，來模擬 Nginx 的客戶端請求：# -S 參數(shù)表示設(shè)置 TCP 協(xié)議的 SYN(同步序列號)，-p 表示目的端口為 80 # -i u100 表示每隔 100 微秒發(fā)送一個網(wǎng)絡(luò)幀 # 注：如果你在實踐過程中現(xiàn)象不明顯，可以嘗試把 100 調(diào)小，比如調(diào)成 10 甚至 1 $ hping3 -S -p 80 -i u100 192.168.0.30現(xiàn)在我們再回到第一個終端，你應(yīng)該發(fā)現(xiàn)了異常。是不是感覺系統(tǒng)響應(yīng)明顯變慢了，即便只是在終端中敲幾個回車，都得很久才能得到響應(yīng)？這個時候應(yīng)該怎么辦呢？雖然在運行 hping3 命令時，我就已經(jīng)告訴你，這是一個 SYN FLOOD 攻擊，你肯定也會想到從網(wǎng)絡(luò)方面入手，來分析這個問題。不過，在實際的生產(chǎn)環(huán)境中，沒人直接告訴你原因。所以，我希望你把 hping3 模擬 SYN FLOOD 這個操作暫時忘掉，然后重新從觀察到的問題開始，分析系統(tǒng)的資源使用情況，逐步找出問題的根源。那么，該從什么地方入手呢？剛才我們發(fā)現(xiàn)，簡單的 SHELL 命令都明顯變慢了，先看看系統(tǒng)的整體資源使用情況應(yīng)該是個不錯的注意，比如執(zhí)行下 top 看看是不是出現(xiàn)了 CPU 的瓶頸。我們在第一個終端運行 top 命令，看一下系統(tǒng)整體的資源使用情況。# top 運行后按數(shù)字 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 ...這里你有沒有發(fā)現(xiàn)異常的現(xiàn)象？我們從第一行開始，逐個看一下：平均負載全是 0，就緒隊列里面只有一個進程(1 running)。每個 CPU 的使用率都挺低，最高的 CPU1 的使用率也只有 4.4%，并不算高。再看進程列表，CPU 使用率最高的進程也只有 0.3%，還是不高呀。那為什么系統(tǒng)的響應(yīng)變慢了呢？既然每個指標的數(shù)值都不大，那我們就再來看看，這些指標對應(yīng)的更具體的含義。畢竟，哪怕是同一個指標，用在系統(tǒng)的不同部位和場景上，都有可能對應(yīng)著不同的性能問題。仔細看 top 的輸出，兩個 CPU 的使用率雖然分別只有 3.3% 和 4.4%，但都用在了軟中斷上；而從進程列表上也可以看到，CPU 使用率最高的也是軟中斷進程 ksoftirqd。看起來，軟中斷有點可疑了。根據(jù)上一期的內(nèi)容，既然軟中斷可能有問題，那你先要知道，究竟是哪類軟中斷的問題。停下來想想，上一節(jié)我們用了什么方法，來判斷軟中斷類型呢？沒錯，還是 proc 文件系統(tǒng)。觀察 /proc/softirqs 文件的內(nèi)容，你就能知道各種軟中斷類型的次數(shù)。不過，這里的各類軟中斷次數(shù)，又是什么時間段里的次數(shù)呢？它是系統(tǒng)運行以來的累積中斷次數(shù)。所以我們直接查看文件內(nèi)容，得到的只是累積中斷次數(shù)，對這里的問題并沒有直接參考意義。因為，這些中斷次數(shù)的變化速率才是我們需要關(guān)注的。那什么工具可以觀察命令輸出的變化情況呢？我想你應(yīng)該想起來了，在前面案例中用過的 watch 命令，就可以定期運行一個命令來查看輸出；如果再加上 -d 參數(shù)，還可以高亮出變化的部分，從高亮部分我們就可以直觀看出，哪些內(nèi)容變化得更快。比如，還是在第一個終端，我們運行下面的命令：$ 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 文件內(nèi)容的變化情況，你可以發(fā)現(xiàn)， TIMER(定時中斷)、NET_RX(網(wǎng)絡(luò)接收)、SCHED(內(nèi)核調(diào)度)、RCU(RCU 鎖)等這幾個軟中斷都在不停變化。其中，NET_RX，也就是網(wǎng)絡(luò)數(shù)據(jù)包接收軟中斷的變化速率最快。而其他幾種類型的軟中斷，是保證 Linux 調(diào)度、時鐘和臨界區(qū)保護這些正常工作所必需的，所以它們有一定的變化倒是正常的。那么接下來，我們就從網(wǎng)絡(luò)接收的軟中斷著手，繼續(xù)分析。既然是網(wǎng)絡(luò)接收的軟中斷，第一步應(yīng)該就是觀察系統(tǒng)的網(wǎng)絡(luò)接收情況。這里你可能想起了很多網(wǎng)絡(luò)工具，不過，我推薦今天的主人公工具 sar 。sar 可以用來查看系統(tǒng)的網(wǎng)絡(luò)收發(fā)情況，還有一個好處是，不僅可以觀察網(wǎng)絡(luò)收發(fā)的吞吐量(BPS，每秒收發(fā)的字節(jié)數(shù))，還可以觀察網(wǎng)絡(luò)收發(fā)的 PPS，即每秒收發(fā)的網(wǎng)絡(luò)幀數(shù)。我們在第一個終端中運行 sar 命令，并添加 -n DEV 參數(shù)顯示網(wǎng)絡(luò)收發(fā)的報告：# -n DEV 表示顯示網(wǎng)絡(luò)收發(fā)的報告，間隔 1 秒輸出一組數(shù)據(jù) $ 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 表示網(wǎng)卡。
- 第三、四列：rxpck/s 和 txpck/s 分別表示每秒接收、發(fā)送的網(wǎng)絡(luò)幀數(shù)，也就是 PPS。
- 第五、六列：rxkB/s 和 txkB/s 分別表示每秒接收、發(fā)送的千字節(jié)數(shù)，也就是 BPS。
小結(jié)
軟中斷 CPU 使用率(softirq)升高是一種很常見的性能問題。雖然軟中斷的類型很多，但實際生產(chǎn)中，我們遇到的性能瓶頸大多是網(wǎng)絡(luò)收發(fā)類型的軟中斷，特別是網(wǎng)絡(luò)接收的軟中斷。在碰到這類問題時，你可以借用 sar、tcpdump 等工具，做進一步分析。不要害怕網(wǎng)絡(luò)性能，后面我會教你更多的分析方法。總結(jié)
以上是生活随笔為你收集整理的10 | 案例篇：系统的软中断CPU使用率升高，我该怎么办？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 09 | 基础篇：怎么理解Linux软中
- 下一篇： 11 | 套路篇：如何迅速分析出系统CP