10 | 案例篇：系统的软中断CPU使用率升高，我该怎么办？
生活随笔
收集整理的這篇文章主要介紹了
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 應用：# 運行 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。
小結
軟中斷 CPU 使用率(softirq)升高是一種很常見的性能問題。雖然軟中斷的類型很多，但實際生產中，我們遇到的性能瓶頸大多是網絡收發類型的軟中斷，特別是網絡接收的軟中斷。在碰到這類問題時，你可以借用 sar、tcpdump 等工具，做進一步分析。不要害怕網絡性能，后面我會教你更多的分析方法。總結
以上是生活随笔為你收集整理的10 | 案例篇：系统的软中断CPU使用率升高，我该怎么办？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 09 | 基础篇：怎么理解Linux软中
- 下一篇： 11 | 套路篇：如何迅速分析出系统CP