Linux中如何解決網(wǎng)卡中斷與CPU綁定問題

這篇文章主要為大家展示了“Linux中如何解決網(wǎng)卡中斷與CPU綁定問題”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“Linux中如何解決網(wǎng)卡中斷與CPU綁定問題”這篇文章吧。

在Linux的網(wǎng)絡(luò)調(diào)優(yōu)方面，如果你發(fā)現(xiàn)網(wǎng)絡(luò)流量上不去，那么有一個方面需要去查一下：網(wǎng)卡處理網(wǎng)絡(luò)請求的中斷是否被綁定到單個CPU或跟處理其它中斷的是同一個CPU。

網(wǎng)卡與操作系統(tǒng)的交互方式

網(wǎng)卡與操作系統(tǒng)的交互一般有兩種方式：

1. 中斷IRQ

網(wǎng)卡在收到了網(wǎng)絡(luò)信號之后，主動發(fā)送中斷到CPU，而CPU將會立即停下手邊的活以便對這個中斷信號進行分析;

2. DMA(Direct Memory Access)

也就是允許硬件在無CPU干預(yù)的情況下將數(shù)據(jù)緩存在指定的內(nèi)存空間內(nèi)，在CPU合適的時候才處理;

 現(xiàn)在的對稱多核處理器(SMP)上，一塊網(wǎng)卡的IRQ還是只有一個CPU來響應(yīng)，其它CPU無法參與，如果這個CPU還要忙其它的中斷(其它網(wǎng)卡或者其它使用中斷的外設(shè)(比如磁盤))，那么就會形成瓶頸。

檢查環(huán)境

首先，讓網(wǎng)絡(luò)跑滿。如：對于MySQL/MongoDB服務(wù)，可以通過客戶端發(fā)起密集的讀操作  或執(zhí)行一個大文件傳送任務(wù)。查明是不是某個CPU在一直忙著處理IRQ?

從 mpstat -P ALL 1 輸出里面的 %irq一列即說明了哪個CPU忙于處理中斷的時間占比;

上面的例子中，第四個CPU有25.63%時間在忙于處理中斷，后面 intr/s  也說明了CPU每秒處理的中斷數(shù)。從上面的數(shù)據(jù)可以看出，其它幾個CPU都不怎么處理中斷。

那么，這些忙于處理中斷的CPU都在處理哪些中斷?

這里記錄的是自啟動以來，每個CPU處理各類中斷的數(shù)量。第一列是中斷號，最后一列是對應(yīng)的設(shè)備名。從上面可以看到： eth0所出發(fā)的中斷全部都是  CPU0在處理，而CPU0所處理的中斷請求中，主要是eth0和LOC中斷。有時我們會看到幾個CPU對同一個中斷類型所處理的的請求數(shù)相差無幾(比如上面的LOC)，這并不一定是說多個CPU會輪流處理同一個中斷，而是因為這里記錄的是“自啟動以來”的統(tǒng)計，中間可能因為irq  balancer重新分配過處理中斷的CPU。

解決思路

現(xiàn)在的多數(shù)Linux系統(tǒng)中都有IRQ Balance這個服務(wù)(服務(wù)程序一般是  /usr/sbin/irqbalance)，它可以自動調(diào)節(jié)分配各個中斷與CPU的綁定關(guān)系，以避免所有中斷的處理都集中在少數(shù)幾個CPU上。在某些情況下，這個IRQ  Balance反而會導(dǎo)致問題，會出現(xiàn) irqbalance 這個進程反而自身占用了較高的CPU(當然也就影響了業(yè)務(wù)系統(tǒng)的性能)。

首先要看該網(wǎng)卡的中斷當前是否已經(jīng)限定到某些CPU了?具體是哪些CPU?

根據(jù)上面 /proc/interrupts 的內(nèi)容我們可以看到 eth0 的中斷號是74，然后我們來看看該中斷號的CPU綁定情況或者說叫親和性  affinity。

$ sudo cat /proc/irq/74/smp_affinity ffffff

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

修改配置的方法:(設(shè)置為2表示將該中斷綁定到CPU1上，0x2 = 0b10，而第一個CPU為CPU0)

echo 2 > /proc/irq/74/smp_affinity

以上是“Linux中如何解決網(wǎng)卡中斷與CPU綁定問題”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注億速云行業(yè)資訊頻道！