共計 1523 個字符，預計需要花費 4 分鐘才能閱讀完成。
這篇文章主要為大家展示了“Linux 中如何解決網卡中斷與 CPU 綁定問題”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓丸趣 TV 小編帶領大家一起研究并學習一下“Linux 中如何解決網卡中斷與 CPU 綁定問題”這篇文章吧。
在 Linux 的網絡調優方面，如果你發現網絡流量上不去，那么有一個方面需要去查一下：網卡處理網絡請求的中斷是否被綁定到單個 CPU 或跟處理其它中斷的是同一個 CPU。
網卡與操作系統的交互方式
網卡與操作系統的交互一般有兩種方式：
1. 中斷 IRQ
網卡在收到了網絡信號之后，主動發送中斷到 CPU，而 CPU 將會立即停下手邊的活以便對這個中斷信號進行分析;
2. DMA(Direct Memory Access)
也就是允許硬件在無 CPU 干預的情況下將數據緩存在指定的內存空間內，在 CPU 合適的時候才處理;
現在的對稱多核處理器 (SMP) 上，一塊網卡的 IRQ 還是只有一個 CPU 來響應，其它 CPU 無法參與，如果這個 CPU 還要忙其它的中斷(其它網卡或者其它使用中斷的外設(比如磁盤))，那么就會形成瓶頸。
檢查環境
首先，讓網絡跑滿。如：對于 MySQL/MongoDB 服務，可以通過客戶端發起密集的讀操作 或執行一個大文件傳送任務。查明是不是某個 CPU 在一直忙著處理 IRQ?
從 mpstat -P ALL 1 輸出里面的 %irq 一列即說明了哪個 CPU 忙于處理中斷的時間占比;
上面的例子中，第四個 CPU 有 25.63% 時間在忙于處理中斷，后面 intr/s 也說明了 CPU 每秒處理的中斷數。從上面的數據可以看出，其它幾個 CPU 都不怎么處理中斷。
那么，這些忙于處理中斷的 CPU 都在處理哪些中斷?
這里記錄的是自啟動以來，每個 CPU 處理各類中斷的數量。第一列是中斷號，最后一列是對應的設備名。從上面可以看到：eth0 所出發的中斷全部都是 CPU0 在處理，而 CPU0 所處理的中斷請求中，主要是 eth0 和 LOC 中斷。有時我們會看到幾個 CPU 對同一個中斷類型所處理的的請求數相差無幾(比如上面的 LOC)，這并不一定是說多個 CPU 會輪流處理同一個中斷，而是因為這里記錄的是“自啟動以來”的統計，中間可能因為 irq balancer 重新分配過處理中斷的 CPU。
解決思路
現在的多數 Linux 系統中都有 IRQ Balance 這個服務(服務程序一般是 /usr/sbin/irqbalance)，它可以自動調節分配各個中斷與 CPU 的綁定關系，以避免所有中斷的處理都集中在少數幾個 CPU 上。在某些情況下，這個 IRQ Balance 反而會導致問題，會出現 irqbalance 這個進程反而自身占用了較高的 CPU(當然也就影響了業務系統的性能)。
首先要看該網卡的中斷當前是否已經限定到某些 CPU 了? 具體是哪些 CPU?
根據上面 /proc/interrupts 的內容我們可以看到 eth0 的中斷號是 74，然后我們來看看該中斷號的 CPU 綁定情況或者說叫親和性 affinity。
$ sudo cat /proc/irq/74/smp_affinity ffffff這個輸出是一個 16 進制的數值，0xffffff = 0b111111111111111111111111，這就意味著這里有 24 個 CPU，所有位都為 1 表示所有 CPU 都可以被該中斷干擾。
修改配置的方法:(設置為 2 表示將該中斷綁定到 CPU1 上，0x2 = 0b10，而第一個 CPU 為 CPU0)
echo 2 /proc/irq/74/smp_affinity以上是“Linux 中如何解決網卡中斷與 CPU 綁定問題”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注丸趣 TV 行業資訊頻道！
