這篇文章主要介紹“Nginx服務(wù)器上軟中斷過高問題如何解決”，在日常操作中，相信很多人在Nginx服務(wù)器上軟中斷過高問題如何解決問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對(duì)大家解答”Nginx服務(wù)器上軟中斷過高問題如何解決”的疑惑有所幫助！接下來，請(qǐng)跟著小編一起來學(xué)習(xí)吧！

目前創(chuàng)新互聯(lián)已為上千家的企業(yè)提供了網(wǎng)站建設(shè)、域名、雅安服務(wù)器托管、網(wǎng)站托管維護(hù)、企業(yè)網(wǎng)站設(shè)計(jì)、環(huán)縣網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

前些天發(fā)現(xiàn)XEN虛擬機(jī)上的Nginx服務(wù)器存在一個(gè)問題：軟中斷過高，而且大部分都集中在同一個(gè)CPU，一旦系統(tǒng)繁忙，此CPU就會(huì)成為木桶的短板。

在問題服務(wù)器上運(yùn)行「top」命令可以很明顯看到「si」存在異樣，大部分軟中斷都集中在 1 號(hào)CPU上，其它的CPU完全使不上勁兒：

shell> top
Cpu0: 11.3%us,  4.7%sy,  0.0%ni, 82.5%id,  ...  0.8%si,  0.8%st
Cpu1: 21.3%us,  7.4%sy,  0.0%ni, 51.5%id,  ... 17.8%si,  2.0%st
Cpu2: 16.6%us,  4.5%sy,  0.0%ni, 77.7%id,  ...  0.8%si,  0.4%st
Cpu3: 15.9%us,  3.6%sy,  0.0%ni, 79.3%id,  ...  0.8%si,  0.4%st
Cpu4: 17.7%us,  4.9%sy,  0.0%ni, 75.3%id,  ...  1.2%si,  0.8%st
Cpu5: 23.6%us,  6.6%sy,  0.0%ni, 68.1%id,  ...  0.9%si,  0.9%st
Cpu6: 18.1%us,  4.9%sy,  0.0%ni, 75.7%id,  ...  0.4%si,  0.8%st
Cpu7: 21.1%us,  5.8%sy,  0.0%ni, 71.4%id,  ...  1.2%si,  0.4%st

查詢一下軟中斷相關(guān)數(shù)據(jù)，發(fā)現(xiàn)主要集中在 NET_RX 上，猜測(cè)是網(wǎng)卡問題：

shell> watch -d -n 1 'cat /proc/softirqs'
                CPU0       CPU1       CPU2 ...       CPU7
      HI:          0          0          0 ...          0
   TIMER: 3692566284 3692960089 3692546970 ... 3693032995
  NET_TX:  130800410  652649368  154773818 ...  308945843
  NET_RX:  443627492 3802219918  792341500 ... 2546517156
   BLOCK:          0          0          0 ...          0
BLOCK_IOPOLL:      0          0          0 ...          0
 TASKLET:          0          0          0 ...          0
   SCHED: 1518716295  335629521 1520873304 ... 1444792018
 HRTIMER:        160       1351        131 ...        196
     RCU: 4201292019 3982761151 4184401659 ... 4039269755

補(bǔ)充：有一個(gè)查看中斷（Interrupt）的top風(fēng)格小工具 itop ，推薦試試。

確認(rèn)一下宿主機(jī)上的網(wǎng)卡信息，發(fā)現(xiàn)其運(yùn)行在單隊(duì)列模式下：

shell> grep -A 10 -i network /var/log/dmesg
Initalizing network drop monitor service
Intel(R) Gigabit Ethernet Network Driver - version 3.0.19
igb 0000:05:00.0: Intel(R) Gigabit Ethernet Network Connection
igb 0000:05:00.0: eth0: (PCIe:2.5GT/s:Width x4) 00:1b:21:bf:b3:2c
igb 0000:05:00.0: eth0: PBA No: G18758-002
igb 0000:05:00.0: Using MSI-X ... 1 rx queue(s), 1 tx queue(s)
igb 0000:05:00.1: Intel(R) Gigabit Ethernet Network Connection
igb 0000:05:00.1: eth2: (PCIe:2.5GT/s:Width x4) 00:1b:21:bf:b3:2d
igb 0000:05:00.1: eth2: PBA No: G18758-002
igb 0000:05:00.1: Using MSI-X ... 1 rx queue(s), 1 tx queue(s)

接著確認(rèn)一下網(wǎng)卡的中斷號(hào)，因?yàn)槭菃侮?duì)列，所以只有一個(gè)中斷號(hào) 45：

shell> grep eth /proc/interrupts | awk '{print $1, $NF}'
45: eth0

知道了網(wǎng)卡的中斷號(hào)，就可以查詢其中斷親緣性配置「smp_affinity」：

shell> cat /proc/irq/45/smp_affinity
02

這里的 02 實(shí)際上是十六進(jìn)制，表示 1 號(hào)CPU，計(jì)算方法如下（參考資料）：

  Binary       Hex 
  CPU 0    0001         1 
  CPU 1    0010         2
  CPU 2    0100         4
+ CPU 3    1000         8
  -----------------------
  both     1111         f

說明：如果 4 個(gè)CPU都參與中斷處理，那么設(shè)為 f；同理 8 個(gè)CPU的就設(shè)置成 ff：

shell> echo ff > /proc/irq/45/smp_affinity

此外還有一個(gè)類似的配置「smp_affinity_list」：

shell> cat /proc/irq/45/smp_affinity_list
1

兩個(gè)配置是相通的，修改了一個(gè)，另一個(gè)會(huì)跟著變。不過「smp_affinity_list」使用的是十進(jìn)制，相比較「smp_affinity」的十六進(jìn)制，可讀性更好些。

了解了這些基本知識(shí)，我們可以嘗試換一個(gè)CPU試試看會(huì)發(fā)生什么：

echo 0 > /proc/irq/45/smp_affinity_list

再通過「top」命令觀察，會(huì)發(fā)現(xiàn)處理軟中斷的CPU變成了 0 號(hào)CPU。

說明：如果希望多個(gè)CPU參與中斷處理的話，可以使用類似下面的語法：

echo 3,5 > /proc/irq/45/smp_affinity_list
echo 0-7 > /proc/irq/45/smp_affinity_list

壞消息是對(duì)單隊(duì)列網(wǎng)卡而言，「smp_affinity」和「smp_affinity_list」配置多CPU無效。

好消息是Linux支持RPS，通俗點(diǎn)來說就是在軟件層面模擬實(shí)現(xiàn)硬件的多隊(duì)列網(wǎng)卡功能。

首先看看如何配置RPS，如果CPU個(gè)數(shù)是 8 個(gè)的話，可以設(shè)置成 ff：

shell> echo ff > /sys/class/net/eth0/queues/rx-0/rps_cpus

接著配置內(nèi)核參數(shù)rps_sock_flow_entries（官方文檔推薦設(shè)置： 32768）：

shell> sysctl net.core.rps_sock_flow_entries=32768

***配置rps_flow_cnt，單隊(duì)列網(wǎng)卡的話設(shè)置成rps_sock_flow_entries即可：

echo 32768 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt

說明：如果是多隊(duì)列網(wǎng)卡，那么就按照隊(duì)列數(shù)量設(shè)置成 rps_sock_flow_entries / N 。

做了如上的優(yōu)化后，我們?cè)龠\(yùn)行「top」命令可以看到軟中斷已經(jīng)分散到了兩個(gè)CPU：

shell> top
Cpu0: 24.8%us,  9.7%sy,  0.0%ni, 52.2%id,  ... 11.5%si,  1.8%st
Cpu1:  8.8%us,  5.1%sy,  0.0%ni, 76.5%id,  ...  7.4%si,  2.2%st
Cpu2: 17.6%us,  5.1%sy,  0.0%ni, 75.7%id,  ...  0.7%si,  0.7%st
Cpu3: 11.9%us,  7.0%sy,  0.0%ni, 80.4%id,  ...  0.7%si,  0.0%st
Cpu4: 15.4%us,  6.6%sy,  0.0%ni, 75.7%id,  ...  1.5%si,  0.7%st
Cpu5: 20.6%us,  6.9%sy,  0.0%ni, 70.2%id,  ...  1.5%si,  0.8%st
Cpu6: 12.9%us,  5.7%sy,  0.0%ni, 80.0%id,  ...  0.7%si,  0.7%st
Cpu7: 15.9%us,  5.1%sy,  0.0%ni, 77.5%id,  ...  0.7%si,  0.7%st

疑問：理論上講，我已經(jīng)設(shè)置了RPS為ff，應(yīng)該所有 8 個(gè)CPU一起分擔(dān)軟中斷才對(duì)，可實(shí)際結(jié)果只有兩個(gè)，有知道原因的請(qǐng)賜教，但是不管怎么說，兩個(gè)總好過一個(gè)。

此外，因?yàn)檫@是一臺(tái)Nginx服務(wù)器，所以通過「worker_cpu_affinity」指令可以配置Nginx使用哪些CPU，如此一來我們便可以繞開高負(fù)載的CPU，對(duì)性能會(huì)有一些幫助。

補(bǔ)充：如果服務(wù)器是NUMA架構(gòu)的話，那么「numactl –cpubind」可能也會(huì)有用。

到此，關(guān)于“Nginx服務(wù)器上軟中斷過高問題如何解決”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！

分享文章：Nginx服務(wù)器上軟中斷過高問題如何解決
文章鏈接：http://chinadenli.net/article0/gichio.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供面包屑導(dǎo)航、小程序開發(fā)、響應(yīng)式網(wǎng)站、Google、品牌網(wǎng)站制作、網(wǎng)頁設(shè)計(jì)公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)