在我的前一篇文章 Linux系統下CPU性能問題分析案例（上）中介紹了CPU使用率的重要指標，包括User、System、Idle、IOwait、Irq、Softirq、Steal、Guest等CPU時間的說明，通過具體案例分析了User、Iowait等CPU使用率過高的排查思路，感興趣的可以回去翻看，今天我們來對看下中斷對CPU影響的案例和分析過程。

基本概念

我們常說的中斷是什么？

硬中斷：

• 概念： 硬中斷是由硬件設備發送給CPU的一種中斷信號。這可以是來自外部設備（如磁盤、網絡接口卡、鍵盤）的信號，需要CPU的處理。
• 工作原理： 當硬件設備需要CPU的處理時，它會發送一個硬中斷信號，中斷控制器接收到信號后將其傳遞給CPU。CPU會立即中斷當前執行的任務，保存當前狀態，然后執行與中斷相關的中斷處理程序。（硬件觸發，快速執行）

軟中斷：

• 概念： 軟中斷是由軟件生成的中斷信號，通常是由內核或操作系統的組件觸發的，而不是外部硬件設備。
• 工作原理： 軟中斷是通過在內存中設置一個特殊的中斷標志位來觸發的。當CPU執行到一個允許軟中斷的位置時，它會檢查這個標志位，如果被設置，CPU將跳轉到相應的軟中斷處理程序執行。（內核觸發，延遲執行）

中斷處理程序：

• 概念： 中斷處理程序是用于響應中斷事件的一段代碼，它負責處理中斷并執行必要的操作。
• 工作原理： 當中斷被觸發，CPU會跳轉到相應的中斷處理程序。中斷處理程序執行與中斷相關的任務，可能包括保存當前狀態、處理中斷源產生的事件、執行特定的操作，最后恢復先前的執行狀態。

如何查看軟中斷和內核線程？

• /proc/interrupts 提供了硬中斷的運行情況（系統硬件觸發，不需要太關注）
• /proc/softirqs 提供了軟中斷的運行情況（下圖中第一列是中斷類型，后面案例分析會說到）

不同軟中斷類型在每個CPU上的累積運行次數

內核中斷線程

軟中斷CPU使用率升高，我該怎么辦？

案例現象

• 軟中斷線程（ksoftirqd/1）使用率超高，處理中斷的CPU占比也很高。

分析過程

1、使用watch動態觀測，確認是什么類型的軟中斷？

watch -d "/bin/cat /proc/softirqs"

分析結果

• TIMER(定時中斷)、 NET_RX(網絡接收)、SCHED(內核調度)、RCU(RCU 鎖)等這幾個軟中斷都在不停變化。
• 而 NET_RX，就是網絡數據包接收軟中斷的變化速率最快。
• 其他幾種類型的軟中斷，是保證 Linux 調度、時鐘、臨界區保護這些正常工作所必需的，所以有變化時正常的。

2、使用sar查詢網絡收發情況

# 使用sar是因為不僅可以觀察網絡收發的吞吐量（BPS），還可以觀察網絡收發的網絡幀數（ PPS）
sar -n DEV 1

分析結果

• 網卡ens33：每秒接收的網絡幀數比較大，幾乎達到8w，而發送的網絡幀數較小，只有接近4w；每秒接收的千字節數只有 4611 KB，發送的千字節數更小，只有2314 KB（接收的PPS達到8w，但接收的BPS只有5k不到，網絡幀看起來是比較小的）。
• docker0和veth04076e3：數據跟 ens33 基本一致只是發送和接收相反，發送的數據較大而接收的數據較小，這是 Linux 內部網橋轉發導致的，屬于正常情況。

3、使用tcpdump抓包一探究竟

tcpdump -i ens33 -n tcp port 80

分析結果

• Flags [S]: 表示這是一個SYN包。而且是大量的SYN在發過來，很明顯這就是SYN FLOOD攻擊。
• SYN FLOOD解決方法。
• 如果有防護設備（F5等），通過硬件來防護。
• 利用iptables臨時封掉攻擊的IP或IP號段，也可以根據訪問頻次來限制。
• 優化系統內核相關參數，增加抵御能力。這個后期會在后期單獨詳細解決。