密集負載下的網卡中斷負載均衡smp affinity及單隊列RPS

簡單的說就是，每一個硬件設備（如：硬盤、網卡等）都須要和 CPU 有某種形式的通訊以便 CPU 及時知道發生了什麼事情，這樣 CPU 可能就會放下手中的事情去處理應急事件，硬件設備主動打擾 CPU 的現象就是硬件中斷。

關於SMP IRQ affinity？

新的內核, Linux改進了分配特定中斷到指定的處理器(或處理器組)的功能. 這被稱爲SMP IRQ affinity, 它能夠控制系統如何響應各類硬件事件. 容許你限制或者從新分配服務器的工做負載, 從而讓服務器更有效的工做. 以網卡中斷爲例，在沒有設置SMP IRQ affinity時， 全部網卡中斷都關聯到CPU0, 這致使了CPU0負載太高，而沒法有效快速的處理網絡數據包，致使了瓶頸。 經過SMP IRQ affinity， 把網卡多箇中斷分配到多個CPU上，能夠分散CPU壓力，提升數據處理速度。

irqbalance的一些個介紹

irqbalance 用於優化中斷分配,它會自動收集系統數據以分析使用模式,並依據系統負載情況將工做狀態置於 Performance mode 或 Power-save mode.處於 Performance mode時irqbalance 會將中斷儘量均勻地分發給各個CPU以充分利用 CPU 多核,提高性能.處於 Power-save mode時,irqbalance 會將中斷集中分配給第一個 CPU,以保證其它空閒 CPU 的睡眠時間,下降能耗。

在沒有配置SMP IRQ affinity，也沒有開啓irqbalance的時候~

在配置了SMP IRQ affinity，啓動了RPS，關閉irqbalance

在做網絡程序的時候, 常常須要了解interrupts和軟中斷的平衡狀況, 須要知道每秒有多少中斷髮生,發生在哪一個cpu上.
Linux下中斷來源信息能夠從 /proc/interrupts 中瞭解到~

你們會看到他的頻率是同樣的，由於咱們這邊已經開了irqbalance，這個東西在負載不大的狀況下，是個很不錯的服務，他的主要功能是能夠合理的調配使用各個CPU核心，特別是對於目前主流多核心的CPU，簡單的說就是可以把壓力均勻的分配到各個CPU核心上，對提高性能有很大的幫助。

[root@102 ~]# service irqbalance status
irqbalance (pid  21745) is running...
[root@102 ~]#

首先咱們能夠經過訪問/proc/cpuinfo的信息查看到cpu的具體信息。

獲取eth0網卡的中斷irq號，而且賦值給shell變量

關閉irqbalance自動分配服務，好讓我們手動分配中斷請求`

/etc/init.d/irqbalance stop

指定CPU來處理對應網卡的中斷請求

我這裏是選擇cpu2來處理這個網卡中斷~

這裏的4是cpu的16進製表達式

CPU              Binary          oct

CPU 0    00000001         1

CPU 1    00000010         2

CPU 2    00000100         4

CPU 3    00001000         8

這裏分享一個腳本，直接算就能夠了~

#!/bin/bash
#
echo "統計cpu的16進制"
[ $# -ne 1 ] && echo ‘$1 is Cpu core number’ && exit 1
CCN=$1
echo 「Print eth0 affinity」
for((i=0; i<${CCN}; i++))
do
echo ==============================
echo "Cpu Core $i is affinity"
((affinity=(1<<i)))
echo "obase=16;${affinity}" | bc
done

要是cpu是8核心的~

要是16個核心的~

[root@102 ~]# sh run.sh  16
統計cpu的16進制
「Print eth0 affinity」
==============================
Cpu Core 0 is affinity
1
==============================
Cpu Core 1 is affinity
2
==============================
Cpu Core 2 is affinity
4
==============================
Cpu Core 3 is affinity
8
==============================
Cpu Core 4 is affinity
10
==============================
Cpu Core 5 is affinity
20
==============================
Cpu Core 6 is affinity
40
==============================
Cpu Core 7 is affinity
80
==============================
Cpu Core 8 is affinity
100
==============================
Cpu Core 9 is affinity
200
==============================
Cpu Core 10 is affinity
400
==============================
Cpu Core 11 is affinity
800
==============================
Cpu Core 12 is affinity
1000
==============================
Cpu Core 13 is affinity
2000
==============================
Cpu Core 14 is affinity
4000
==============================
Cpu Core 15 is affinity
8000

而後對於smp_affinity的配置，根據16進制的cpu數目來算的，你要是輸入5的話，那意思就是說  cpu0 和cpu2都參與進去了。

你們還會注意到，目錄下還有個smp_affinity_list ，他是十進制的表達方式

兩個配置是相通的，smp_affinity_list使用的是十進制，相比較smp_affinity的十六進制，可讀性更好些。

echo 3,8 > /proc/irq/31/smp_affinity_list
echo 0-4 > /proc/irq/31/smp_affinity_list

利用watch查看切換後的效果

[root@102 ~]# watch -n 2 "cat /proc/interrupts |grep eth"

好了，須要說明的是：

對單隊列網卡而言，smp_affinity和smp_affinity_list配置多CPU是沒有效果的。這話也不是絕對的，我們能夠用RPS來搞定。

該功能主要針對單隊列網卡多CPU環境，如網卡支持多隊列則可以使用SMP irq affinity直接綁定硬中斷，要是不支持多隊列，那就用RPS解決網絡軟中斷的負載均衡，即單個網卡的軟中斷分散到多個CPU處理，避免單個CPU負載過大致使性能瓶頸。

如何肯定你的網卡支持多隊列~
最右面的那些就是多隊列的信息了

這個是4隊列的~

這個是8隊列的~

這裏用的機型是IBM x3630 m3

網卡是MSI-X的

事實上在一個大量小包的系統上，irqbalance優化幾乎沒有效果，並且還使得cpu消耗分配的不均衡，致使機器性能得不到充分的利用，這個時候須要把它給結束掉。而後我們用手動的方法配置下。

無論怎麼說，在同等條件下強烈你們選用多隊列的網卡，常見的有Intel的8257五、82576，Boardcom的57711等。

多隊列網卡是一種技術，最初是用來解決網絡IO QoS 問題的，隨着網絡IO的帶寬的不斷提高，單核CPU不能徹底處知足網卡的需求，經過多隊列網卡驅動的支持，將各個隊列經過中斷綁定到不一樣的核上。其實用bonding網卡綁定在必定程度也能夠作中斷負載均衡，兩個網卡中斷號能夠綁定在不一樣的cpu核心上。

因爲RPS只是單純把數據包均衡到不一樣的cpu，這個時候若是應用程序所在的cpu和軟中斷處理的cpu不是同一個，此時對於cpu cache的影響會很大，那麼RFS確保應用程序處理的cpu跟軟中斷處理的cpu是同一個，這樣就充分利用cpu的cache.

有兩種配置的方法：

把每一個隊列連到一個cpu上

/proc/sys/net/core/rps_sock_flow_entries 32768
/sys/class/net/eth0/queues/rx-0/rps_cpus 00000001
/sys/class/net/eth0/queues/rx-1/rps_cpus 00000002
/sys/class/net/eth0/queues/rx-2/rps_cpus 00000004
/sys/class/net/eth0/queues/rx-3/rps_cpus 00000008
/sys/class/net/eth0/queues/rx-0/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-1/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-2/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-3/rps_flow_cnt 4096

另外一種是推薦的方法：   這個方法在多方面測試下，能夠很好的均衡下來。

/sys/class/net/eth0/queues/rx-0/rps_cpus 000000ff
/sys/class/net/eth0/queues/rx-1/rps_cpus 000000ff
/sys/class/net/eth0/queues/rx-2/rps_cpus 000000ff
/sys/class/net/eth0/queues/rx-3/rps_cpus 000000ff
/sys/class/net/eth0/queues/rx-0/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-1/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-2/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-3/rps_flow_cnt 4096
/proc/sys/net/core/rps_sock_flow_entries 32768

總結下：

RPS/RFS主要是針對單隊列網卡多CPU環境。雖然有這些虛擬隊列的支撐，可是畢竟是軟件模擬的。 強烈推薦用支持多隊列的網卡。

多隊列多重中斷的網卡在使用了smp affinity以後也能夠再使用該RFS RPS的功能，在這裏他更像是個接收方的調解員，最大程度的提升cpu cache。

本身的一些理解，要是有不對的地方，請朋友們噴之 ！

這兩天會把測試的結果貼上來，6樓的庫房停電了，從哥們拿申請了幾個R720xd的測試機器都連不上了 ！  

這邊的網絡測試用的是  netperf ~

tar -xzvf netperf-2.5.0.tar.gz
cd netperf-2.5.0
./configure
make
make install

用法：

根據做用範圍的不一樣，netperf的命令行參數能夠分爲兩大類：全局命令行參數、測試相關的局部參數，二者之間使用--分隔：
Netperf [global options] –-[test-specific options]
其中：
全局命令行參數包括以下選項：
-H host ：指定遠端運行netserver的server IP地址。
-l testlen：指定測試的時間長度（秒）
-t testname：指定進行的測試類型，包括TCP_STREAM，UDP_STREAM，TCP_RR，TCP_CRR，UDP_RR
測試相關的局部參數包括以下選項：
-s size 設置本地系統的socket發送與接收緩衝大小
-S size 設置遠端系統的socket發送與接收緩衝大小
-m size 設置本地系統發送測試分組的大小
-M size 設置遠端系統接收測試分組的大小
-D 對本地與遠端系統的socket設置TCP_NODELAY選項

102 是請求端，能夠看到他的網卡跑盡是118M左右。

101是服務端 ～

我們看看客戶端的結果：

udp壓力測試下

1）遠端系統（即server）使用大小爲229376字節的socket接收緩衝

2）本地系統（即client）使用大小爲65507字節的socket發送緩衝

3）測試經歷的時間爲120秒

4）吞吐量的測試結果爲961 Mbits/秒

tcp壓力測試下

1）遠端系統（即server）使用大小爲87380字節的socket接收緩衝

2）本地系統（即client）使用大小爲16384字節的socket發送緩衝

3）測試經歷的時間爲120秒

4）吞吐量的測試結果爲941 Mbits/秒