概述

​ 在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_affinityffffff

​ 這個輸出是一個16進位制的數值，0xffffff = '0b111111111111111111111111'，這就意味著這裡有24個CPU，所有位都為1表示所有CPU都可以被該中斷干擾。

​ 修改配置的方法:

（設定為2表示將該中斷繫結到CPU1上，0x2 = 0b10，而第一個CPU為CPU0）

echo 2 > /proc/irq/74/smp_affinity

後面會分享更多devops和DBA方面的內容，感興趣的朋友可以關注下~