■ 河南 劉京義

編者按：筆者遇到一例服務(wù)器異常丟包的問題，一般來說該故障大多是由帶寬被占滿引發(fā)的，但這次的故障卻并不是帶寬引起的，究竟是什么原因呢？

某單位數(shù)據(jù)中心的一臺(tái)服務(wù)器最近經(jīng)常出現(xiàn)異常丟包的問題。其表現(xiàn)為在訪問量不大的情況下一切正常，但是如果數(shù)據(jù)流量很大時(shí)，就會(huì)不斷出現(xiàn)丟包的問題，給正常的業(yè)務(wù)帶來的很大的影響。

該服務(wù)器安裝的是Cent OS 6.X系統(tǒng)，使用的是四核的CPU和16GB的內(nèi)存。既然是丟包故障，很可能是因?yàn)閹捳紳M引發(fā)的，但是查看相關(guān)的監(jiān)控信息，發(fā)現(xiàn)其使用的千兆網(wǎng)卡上流量才幾百兆每秒，并沒有占滿帶寬，顯然并不是因?yàn)樵搯栴}引發(fā)的。

故障排查

登錄到該機(jī)上，執(zhí)行“top”命令，在返回信息中的“l(fā)oad average”欄中顯示系統(tǒng)的負(fù)荷并不大，在“Kib Mem”欄中顯示內(nèi)存使用量一般，還有大量的空閑內(nèi)存，顯然并不是因?yàn)橄到y(tǒng)超負(fù)荷運(yùn)行導(dǎo)致的上述問題。

但 是，在“%Cpu(s)：”欄中的“si”項(xiàng)的數(shù)值為39.1，對(duì) 于“si”（即time spent servicing software interrupts）來說，表示的是軟中斷占用CPU資源的百分比，這里的數(shù)值明顯過高，上述故障是不是因?yàn)橹袛喈惓Ｔ斐傻哪兀?/p>

因此，執(zhí)行“cat/proc/interrupts”命令，查看系統(tǒng)中斷情況。在返回信息中顯示所有設(shè)備的中斷分布參數(shù)，其中第一列為具體的中斷 號(hào)，從“cpu0”到“cpu3”各列中顯示各CPU核心處理的中斷數(shù)量。在最后一列顯示與中斷號(hào)對(duì)應(yīng)的硬件設(shè)備名稱，不同的設(shè)備使用的中斷號(hào)是不同的。例如，時(shí)鐘的中斷號(hào)為0，鍵盤中斷號(hào)為1，硬盤中斷號(hào)為15，網(wǎng)卡中斷號(hào)為16等。并且中斷是具有優(yōu)先級(jí)的，中斷號(hào)越小其擁有的優(yōu)先級(jí)越高。

從網(wǎng)卡“eth0”對(duì)應(yīng)的中斷分布情況來看，從系統(tǒng)啟動(dòng)至今CPU1處理的中斷數(shù)量最多，達(dá)到幾百萬次。但是其他幾個(gè)CPU核心處理的中斷則很少，甚至為0，這說明多核CPU對(duì)于網(wǎng)卡中斷的處理是不均衡的。

對(duì)于不同的計(jì)算機(jī)硬件來說，其和CPU進(jìn)行通訊實(shí)際上是通過中斷實(shí)現(xiàn)的。例如當(dāng)網(wǎng)卡接收到數(shù)據(jù)包時(shí)，就會(huì)產(chǎn)生中斷信號(hào)給CPU，CPU就會(huì)中斷當(dāng)前的工作，通知系統(tǒng)內(nèi)核有新的數(shù)據(jù)包到來，內(nèi)核就會(huì)調(diào)用中斷處理程序加以響應(yīng)，將數(shù)據(jù)包從網(wǎng)卡緩存區(qū)中復(fù)制到內(nèi)存進(jìn)行處理。

如果沒有中斷機(jī)制，那么當(dāng)網(wǎng)卡緩沖區(qū)發(fā)生溢出時(shí)，就會(huì)出現(xiàn)數(shù)據(jù)包被丟棄的問題。CPU利用中斷號(hào)來區(qū)分不同的硬件，計(jì)算機(jī)中的不同硬件擁有不同的中斷號(hào)。中斷其實(shí)就是一種電信號(hào)，由硬件產(chǎn)生并發(fā)送到中斷控制器上。中斷分為硬中斷和軟中斷，前者是由硬件主動(dòng)產(chǎn)生，處理速度很快，可以通過CPU屏蔽位進(jìn)行屏蔽。后者是由軟件發(fā)送給系統(tǒng)內(nèi)核的中斷信號(hào)，響應(yīng)速度較慢，屬于指令方式不能屏蔽。

執(zhí)行“mpstat -P ALL 2”命令，按照每隔兩秒的頻率查看所有CPU核心的狀態(tài)信息，在其中的“CPU”列中顯示所有的CPU核心數(shù)，在“%soft”列中顯示對(duì)應(yīng)CPU核心處理的軟中斷數(shù)量，在“%irq”列中顯示其處理的硬中斷數(shù)量?？梢钥吹街挥蠧PU1在忙于處理軟中斷，其余的CPU核心則處于則比較空閑。因?yàn)榫W(wǎng)卡的中斷號(hào)為16，因此執(zhí)行“cat/proc/irq/16/smp_affinity”命令，查看中斷親緣性配置信息。

其對(duì)應(yīng)的參數(shù)為“smp_affinity”，顯示的數(shù)值為2，其使用的是十六進(jìn)制，對(duì)應(yīng)的二進(jìn)制為“0010”，對(duì)應(yīng)的就是CPU1。如果顯示為1/4/8/10/20/40/80的話，對(duì)應(yīng)的是CPU0/2/4/5/6/7/8等。與“smp_affinity”參數(shù)關(guān)聯(lián)還有“smp_affinity_list”，其采用的是十進(jìn)制。兩者的配置信息起著相同的作用。

例如，執(zhí)行“echo 1/proc/irq/16/smp_affinity_list”命令，可以激活CPU0核心處理軟中斷。再次執(zhí)行“mpstat -P ALL 2”命令，可以看到CPU0已經(jīng)開始處理大量的中斷信息了。

故障解決

根據(jù)以上分析，對(duì)于多核CPU來說，在處理網(wǎng)卡中斷時(shí)其實(shí)并沒有發(fā)揮真正的作用，僅僅是其中某個(gè)CPU核心在應(yīng)對(duì)大量的中斷請(qǐng)求。

這對(duì)于一般的應(yīng)用場(chǎng)景來說問題不大，但是對(duì)于高流量的服務(wù)器來說，就顯示難堪重負(fù)了。因?yàn)楦咝阅艿姆?wù)器需要將不同的網(wǎng)卡隊(duì)列綁定到不同的CPU核心上，這樣可以將網(wǎng)卡數(shù)據(jù)包產(chǎn)生的中斷負(fù)載均衡的分布到不同的CPU核心上，避免出現(xiàn)某個(gè)CPU核心忙碌，其它核心閑置的情況，來盡可能的提高多核CPU處理中斷請(qǐng)求的能力，提高服務(wù)器整體的數(shù)據(jù)吞吐能力。

上述故障就是因?yàn)橹挥心硞€(gè)CPU核心處理網(wǎng)卡中斷，無法有效應(yīng)對(duì)大量的網(wǎng)卡數(shù)據(jù)包所產(chǎn)生的中斷請(qǐng)求，數(shù)據(jù)包無法全部復(fù)制到內(nèi)存加以處理，造成網(wǎng)卡緩沖區(qū)溢出引發(fā)丟包故障。

解決的方法是，讓所有的CPU核心都參與處理網(wǎng)卡中斷請(qǐng)求，執(zhí)行“echo f/proc/irq/16/smp_affinity”命令，讓4個(gè)CPU核心全部都用來處理網(wǎng)卡中斷，因?yàn)椤癴”的二進(jìn)制值為“1111”，表示啟用4個(gè)CPU核心。

注意，對(duì)于單隊(duì)列網(wǎng)卡來說，僅僅執(zhí)行上述配置其實(shí)是沒有效果的。

在CentOS6.X及其以上系統(tǒng)中，內(nèi)置了RPS（Receive Packet Steering）和RFS（Receive Flow Steering）功能，可以在軟件層面模擬硬件的多隊(duì)列網(wǎng)卡功能。RPS可以對(duì)網(wǎng)卡接收包中斷中斷進(jìn)行優(yōu)化，將一個(gè)或者多個(gè)隊(duì)列中的軟中斷軟中斷分布到多個(gè)CPU核心上。RFS可以應(yīng)對(duì)應(yīng)用程序所在的CPU核心和中斷處理的CPU核心不一致的情況。

將兩者分配到同一個(gè)CPU核心上。執(zhí)行“echo f/sys/class/net/eth0/queues/rx-0/rps_cpus”命令，來配置RPS功能。

執(zhí)行“sysctl net.core.rps_sock_flow_entries=32768”和“echo 32768/sys/class/net/eth0/queues/rx-0/rps_flow_cnt”命令。配置系統(tǒng)相關(guān)核心參數(shù)，這里采用的是默認(rèn)值。當(dāng)然，網(wǎng)卡的名稱需要根據(jù)實(shí)際情況更改。再次執(zhí)行“mpstat -P ALL 2”命令，可以看到所有的CPU核心都開始處理網(wǎng)卡中斷請(qǐng)求了。當(dāng)然，也可以使用Irqbalance服務(wù)，來將中斷平均分布到雖有的CPU核心上，可以有效提升系統(tǒng)性能。

執(zhí)行“rpm -qa | grep irqbalance”命令，來 查看該服務(wù)安裝情況。如果沒有安裝，可以執(zhí)行“yum search irqbalance”和“yum install irqbalance”命令，來安裝該服務(wù)。執(zhí)行“service irqbalance start”命令，啟動(dòng)該服務(wù)。執(zhí)行“ps -ef|grep irqbalance”命令，查看其運(yùn)行情況。該服務(wù)可以自動(dòng)將中斷分布到所有的CPU核心上，來有效均衡中斷的處理操作。

如果使用的是多隊(duì)列網(wǎng)卡的話，那么就擁有了硬件 的RSS（Receive Side Scaling）功能。它可以根據(jù)網(wǎng)卡的硬件隊(duì)列數(shù)量信息，將各隊(duì)列的中斷分布到多個(gè)CPU核心上。

注意，多隊(duì)列網(wǎng)卡需要對(duì)應(yīng)的驅(qū)動(dòng)支持。執(zhí)行“l(fā)spci-vvv”命令，如果返回信息中的“Ethernet controller”欄中存在“MSI-X,Enable+”之類的信息，在其后的“Count=”中數(shù)量大于1的話，就說明網(wǎng)卡支持多隊(duì)列功能。

之后執(zhí)行“grep eth0/proc/interrupts |awk'{print $NF}'”命 令，可顯示網(wǎng)卡網(wǎng)卡支持的隊(duì)列信息，例如從“eth0-TxRx-0”，“eth0-TxRx-1”到“eth0-TxRx-7”等。執(zhí)行“grep eth0-TxRx/proc/interrupts |awk '{print$1,$NF}'”命 令，顯示 各隊(duì)列對(duì)應(yīng)的中斷號(hào)，例如從161到169等。除了使用irqbalance服務(wù)將對(duì)應(yīng)的隊(duì)列綁定到目標(biāo)CPU核心外，還可以執(zhí)行以下命令，將不同的隊(duì)列綁定到CPU0到CPU4等核心上：

當(dāng)然，如果是8核甚至更多的CPU的話，只需增加對(duì)應(yīng)的的數(shù)量即可。

例如，可以執(zhí)行“echo 80/proc/irq/169/smp_affinity”命令，將第8個(gè)隊(duì)列綁定到CPU8核心上。如果已經(jīng)啟用了irqbalance服務(wù)，那么手動(dòng)分配是無效的。

如果網(wǎng)卡隊(duì)列和CPU核心數(shù)量不匹配，例如CPU是16核的，網(wǎng)卡隊(duì)列數(shù)量為8，將隊(duì)列分別綁定CPU0到7核心，雖然實(shí)現(xiàn)了對(duì)網(wǎng)卡中斷的均衡處理，但是其余的CPU核心依然處于閑置狀態(tài)。為此可以采用軟件方式加以處理。

執(zhí)行：

并以此類推直到執(zhí)行“echo ffff/sys/class/net/eth0/queues/rx-7/rps_cpus”命令，將8個(gè)網(wǎng)卡隊(duì)列全部綁定到所有的CPU核心上，其中的“ffff”表示16核CPU，命令執(zhí)行8次，對(duì)應(yīng)的接收隊(duì)列名稱從“rx-0”到“rx-7”。

執(zhí) 行“sysctl net.core.rps_sock_flow_entries=32768”命令，配置RFS參數(shù)，來增加CPU緩存命中率，減少網(wǎng)絡(luò)延遲。執(zhí)行“l(fā)s/sys/class/net/eth0/queues/rx-*|grep queues|wc -l”命令，顯示接收隊(duì)列的數(shù)量。系統(tǒng)系統(tǒng)默認(rèn)的“rps_sock_flow_entries”參數(shù)表示系統(tǒng)期望的同一時(shí)間的活躍連接數(shù)，默認(rèn)值為“32768”。一般來說，它需要除以網(wǎng)卡接收隊(duì)列數(shù)，來得到“rps_flow_cnt”參數(shù)的值，該參數(shù)和RFS密切相關(guān)。這里假設(shè)為8個(gè)接收隊(duì)列，所以其值為4096。

執(zhí)行以下命令：

并以此類推，直到執(zhí)行“echo 4096/sys/class/net/eth0/queues/rx-7/rps_flow_cnt”命令，分別設(shè)置所有接收隊(duì)列中“rps_flow_cnt”參數(shù)的值。這樣，就可以將網(wǎng)卡所有接收隊(duì)列綁定到16個(gè)CPU核心上，讓所有的CPU核心都可以處理網(wǎng)卡中斷。

當(dāng)然，這里僅僅是舉例說明，具體的網(wǎng)卡名稱和隊(duì)列名稱需要根據(jù)實(shí)際情況來定。