問題
多核CPU遊戲戰鬥服務器高峯期時會出現網絡丟包, 發現CPU0軟中斷%si 太高，致使%id值太低觸發告警緩存
以下圖，在線低峯期軟中斷%si 處理時間百分比高達20多，id值變低，服務器變卡和丟包，影響業務服務器
中斷
什麼是中斷?
指接收來自硬件或者軟件的信號發送給CPU和系統內核進行處理，發出這樣的信號稱爲進行中斷請求(IRQ)網絡
中斷又分爲：負載均衡
硬中斷：外圍硬件好比網卡發給CPU的信號ide
軟中斷：由硬中斷處理後對操做系統內核發出信號的中斷請求性能
查看中斷狀況即CPU都在哪些設備上幹活
經過命令cat /proc/interrupts 查看系統中斷信息，長下面這個樣子的。測試
第一列是中斷號，好比eth0對應的中斷號是35，後面是每一個cpu對應的中斷次數。優化
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0: 127 0 0 0 0 0 0 0 IR-IO-APIC-edge timer 7: 15 0 0 0 0 0 0 0 IR-IO-APIC-edge 8: 182900 0 0 0 0 0 0 0 IR-IO-APIC-edge rtc0 9: 1 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi acpi 23: 18575 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi ehci_hcd:usb1 24: 0 0 0 0 0 0 0 0 DMAR_MSI-edge dmar0 25: 132248 0 0 0 0 0 0 0 IR-HPET_MSI-edge hpet2 26: 0 0 0 0 0 0 0 0 IR-HPET_MSI-edge hpet3 27: 0 0 0 0 0 0 0 0 IR-HPET_MSI-edge hpet4 28: 0 0 0 0 0 0 0 0 IR-HPET_MSI-edge hpet5 29: 0 0 0 0 0 0 0 0 IR-HPET_MSI-edge hpet6 32: 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge aerdrv 33: 2735198364 0 0 0 0 0 0 0 IR-PCI-MSI-edge ahci 34: 1 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0 35: 1157411688 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-0 36: 2199548159 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-1 37: 2210448541 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-2 38: 954381730 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-3 39: 3991435919 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-4 40: 2197207910 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-5 41: 2685654183 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-6 42: 2153260851 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-7NMI: 121456 40118 30875 24931 27000 26053 21459 19945 Non-maskable interruptsLOC: 3074687366 1216301963 1626527541 4049966581 4109422958 2708891166 1813301274 1373418058 Local timer interruptsSPU: 0 0 0 0 0 0 0 0 Spurious interruptsPMI: 121456 40118 30875 24931 27000 26053 21459 19945 Performance monitoring interruptsIWI: 0 0 0 0 0 0 0 0 IRQ work interruptsRES: 2454452061 1303706723 606598429 461072921 965186776 274559675 348785593 347963099 Rescheduling interruptsCAL: 216 682 679 680 583 683 667 668 Function call interruptsTLB: 19837873 5603975 5927817 4380569 12552909 11396903 7656446 6960058 TLB shootdownsTRM: 0 0 0 0 0 0 0 0 Thermal event interruptsTHR: 0 0 0 0 0 0 0 0 Threshold APIC interruptsMCE: 0 0 0 0 0 0 0 0 Machine check exceptionsMCP: 132236 132236 132236 132236 132236 132236 132236 132236 Machine check pollsERR: 15MIS: 0
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 spa
35: 1157411688 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-0從上面能夠看獲得eth0的網卡中斷次數最多，意味着中斷請求都在CPU0上面處理，當然就會出現圖1的狀況操作系統
優化
Linux系統採用中斷機制協同處理CPU與其餘設備工做。網卡的中斷默認由cpu0處理，在大量請求的網絡環境下可能出現cpu0負載高，而其餘cpu空閒。後來出現網卡多隊列技術解決這個問題
RSS（Receive Side Scaling）是網卡的硬件特性，實現了多隊列，能夠將不一樣的中斷次數分發到不一樣的CPU上。多隊列網卡是一種技術，最初是用來解決網絡IO QoS （quality of service）問題的，後來隨着網絡IO的帶寬的不斷提高，單核CPU不能徹底處知足網卡的需求，經過多隊列網卡驅動的支持，將各個隊列經過中斷綁定到不一樣的核上，以知足網卡的需求，同時也能夠下降CPU0的負載，解決圖1的問題
查看網卡是否支持隊列，支持多少個隊列
awk '$NF~/eth/{print $1,$NF}' /proc/interrupts 37: eth0-TxRx-038: eth0-TxRx-139: eth0-TxRx-240: eth0-TxRx-341: eth0-TxRx-442: eth0-TxRx-543: eth0-TxRx-644: eth0-TxRx-7
以上網卡eth0爲例支持隊列，37-44是中斷號， 通常如今主流網卡驅動都支持多隊列，默認是7個隊列
中斷綁定
網卡支持了隊列，意味着咱們就能夠綁定中斷號與處理CPU之間的關係，
Linux系統默認使用irqbalance服務優化中斷分配，它能自動收集數據，調度中斷請求，可是它的分配調度機制極不均勻，不建議開啓，爲了瞭解中斷綁定，咱們把irqbalance服務關掉，手工調整綁定關係。
##相關配置文件：
/proc/irq/中斷號/smp_affinity，中斷IRQ_ID的CPU親和配置文件，16進制
/proc/irq/中斷號/smp_affinity_list，10進制，與smp_affinity相通，修改一個相應改變。
smp_affinity和smp_affinity_list修改其一便可，smp_affinity_list修改更方便
cat /proc/irq/37/smp_affinity01cat /proc/irq/38/smp_affinity_list 01#上面表示01對應cpu0，能夠直接修改綁定關係
echo 0 > /proc/irq/37/smp_affinityecho 1 > /proc/irq/38/smp_affinityecho 2 > /proc/irq/39/smp_affinityecho 3 > /proc/irq/40/smp_affinityecho 4 > /proc/irq/41/smp_affinityecho 5 > /proc/irq/42/smp_affinityecho 6 > /proc/irq/43/smp_affinityecho 7 > /proc/irq/38/smp_affinity
cat /proc/irq/37/smp_affinity_list 0cat /proc/irq/38/smp_affinity_list 1cat /proc/irq/39/smp_affinity_list 2cat /proc/irq/40/smp_affinity_list3cat /proc/irq/41/smp_affinity_list 4cat /proc/irq/42/smp_affinity_list 5cat /proc/irq/43/smp_affinity_list 6cat /proc/irq/44/smp_affinity_list 7#此時中斷號3七、38對應的處理CPU爲cpu一、cpu2，top命令查看%si是否均衡分攤到0-7核CPU
支持RSS的網卡，經過上面這種方法將不一樣的中斷號綁定到每一個CPU上實現了中斷的分配。
RPS/RFS
雖說RSS實現了中斷的分配，可是若是隊列數 < 機器總核數 而且CPU與中斷號一一對應了，會出現軟中斷負載跑在0-7核上，其餘核不處理軟中斷的狀況，0-7核負載依然會很高。RSS須要硬件支持，在只支持單隊列或多隊列的環境中，RPS/RFS提供了軟件的解決方案。
RPS（Receive Packet Steering）是基於RSS軟件方式實現CPU均衡，接收包中斷的優化，是把一個或多個rx隊列的軟中斷分發到多個CPU核上，從而達到全局負載均衡的目的。
RFS（Receive Flow Steering）是RPS的擴展，因爲RPS只是單純的把數據包均衡到不一樣的CPU上，此時若是應用程序所在CPU和中斷處理的CPU不在同一個核，將會對CPU Cache影響很大，RFS的做用就是將應用程序和軟中斷處理分配到同一個CPU
配置RPS
一個十六進制 f 表示四個CPU核，那麼均衡到32核即ffffffff,經研究測試，最大隻支持32核調度分配
rps_cpus='ffffffff'for rxdir in /sys/class/net/eth0/queues/rx-*doecho $rps_cpus >$rxdir/rps_cpusdone
配置RFS
RFS擴展了RPS的性能以增長CPU緩存命中率，減小網絡延遲,默認是禁用的
/proc/sys/net/core/rps_sock_flow_entries
這個值依賴於系統指望的活躍鏈接數，注意是同一時間活躍的鏈接數，這個鏈接數正常來講會大大小於系統能承載的最大鏈接數，由於大部分鏈接不會同時活躍。推薦值是 32768
/sys/class/net/device/queues/rx-queue/rps_flow_cnt
將 device 改成想要配置的網絡設備名稱（例如，eth0），將 rx-queue 改成想要配置的接收隊列名稱（例如，rx-0）。
將此文件的值設爲 rps_sock_flow_entries 除以 N，其中 N 是設備中接收隊列的數量。例如，若是 rps_flow_entries 設爲 32768，而且有 16 個配置接收隊列，那麼 rps_flow_cnt 就應設爲 2048。對於單一隊列的設備，rps_flow_cnt 的值和 rps_sock_flow_entries 的值是同樣的
ls /sys/class/net/eth0/queues/rx-*|grep queues|wc -l8rps_flow_cnt=32768/8=4096echo 32768 >/proc/sys/net/core/rps_sock_flow_entriesfor rxdir in /sys/class/net/eth0/queues/rx-*doecho $rps_cpus >$rxdir/rps_cpusecho $rps_flow_cnt >$rxdir/rps_flow_cntdoneecho 32768 >/proc/sys/net/core/rps_sock_flow_entries
效果
RSS+RPS+RFS 優化事後能夠看到軟中斷已均分到每一個CPU上，%id值均勻，如今看已是比較充分地利用多核CPU了，不用太擔憂單核出現高負載告警的問題。