前些天發現xen虛擬機器上的nginx伺服器存在乙個問題：軟中斷過高，而且大部分都集中在同乙個cpu，一旦系統繁忙，此cpu就會成為木桶的短板。
在問題伺服器上執行「top」命令可以很明顯看到「si」存在異樣，大部分軟中斷都集中在 1 號cpu上，其它的cpu完全使不上勁兒：
shell> top查詢一下軟中斷相關資料，發現主要集中在 net_rx 上，猜測是網絡卡問題：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
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
shell> grep -a 10 -i network /var/log/dmesg接著確認一下網絡卡的中斷號，因為是單佇列，所以只有乙個中斷號 45：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: eth1: (pcie:2.5gt/s:width x4) 00:1b:21:bf:b3:2d
igb 0000:05:00.1: eth1: pba no: g18758-002
igb 0000:05:00.1: using msi-x ... 1 rx queue(s), 1 tx queue(s)
shell> grep eth /proc/interrupts | awk ''知道了網絡卡的中斷號，就可以查詢其中斷親緣性配置「smp_affinity」：45: eth0
shell> cat /proc/irq/45/smp_affinity這裡的 02 實際上是十六進製制，表示 1 號cpu，計算方法如下（參考資料）：02
binary hex說明：如果 4 個cpu都參與中斷處理，那麼設為 f；同理 8 個cpu的就設定成 ff：cpu 0 0001 1
cpu 1 0010 2
cpu 2 0100 4
+ cpu 3 1000 8
-----------------------
both 1111 f
shell> echo ff > /proc/irq/45/smp_affinity此外還有乙個類似的配置「smp_affinity_list」：
shell> cat /proc/irq/45/smp_affinity_list兩個配置是相通的，修改了乙個，另乙個會跟著變。不過「smp_affinity_list」使用的是十進位制，相比較「smp_affinity」的十六進製制，可讀性更好些。1
了解了這些基本知識，我們可以嘗試換乙個cpu試試看會發生什麼：
echo 7 > /proc/irq/45/smp_affinity_list再通過「top」命令觀察，會發現處理軟中斷的cpu變成了 7 號cpu。
說明：如果希望多個cpu參與中斷處理的話，可以使用類似下面的語法：
echo 3,5 > /proc/irq/45/smp_affinity_list壞訊息是對單佇列網絡卡而言，「smp_affinity」和「smp_affinity_list」配置多cpu無效。echo 0-7 > /proc/irq/45/smp_affinity_list
好訊息是linux支援rps，通俗點來說就是在軟體層面模擬實現硬體的多佇列網絡卡功能。
首先看看如何配置rps，如果cpu個數是 8 個的話，可以設定成 ff：
shell> echo ff > /sys/class/net/eth0/queues/rx-0/rps_cpus接著配置核心引數rps_sock_flow_entries（官方文件推薦設定： 32768）：
shell> sysctl net.core.rps_sock_flow_entries=32768最後配置rps_flow_cnt，單佇列網絡卡的話設定成rps_sock_flow_entries即可：
echo 32768 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt說明：如果是多佇列網絡卡，那麼就按照佇列數量設定成 rps_sock_flow_entries / n 。
做了如上的優化後，我們再執行「top」命令可以看到軟中斷已經分散到了兩個cpu：
shell> top疑問：理論上講，我已經設定了rps為ff，應該所有 8 個cpu一起分擔軟中斷才對，可實際結果只有兩個，有知道原因的請賜教，但是不管怎麼說，兩個總好過乙個。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
此外，因為這是一台nginx伺服器，所以通過「worker_cpu_affinity」指令可以配置nginx使用哪些cpu，如此一來我們便可以繞開高負載的cpu，對效能會有一些幫助。
補充：如果伺服器是numa架構的話，那麼「numactl –cpubind」可能也會有用。
最後，推薦看看香草總結的一些關於軟中斷方面的資料和工具，很全面。
this entry was posted in
technical and tagged
linux by
老王. bookmark the
permalink.
記錄乙個軟中斷問題
前些天發現xen虛擬機器上的nginx伺服器存在乙個問題 軟中斷過高，而且大部分都集中在同乙個cpu，一旦系統繁忙，此cpu就會成為木桶的短板。在問題伺服器上執行 top 命令可以很明顯看到 si 存在異樣，大部分軟中斷都集中在 1 號cpu上，其它的cpu完全使不上勁兒 shell top cpu...
乙個PCI中斷非同步的問題
最近發現由於pci資料傳輸錯誤導致io request得到的資料不正確，這種現象讓我們思考，為什麼系統都已經發現了pci錯誤，io request還能正確結束呢？按照慣例思考，pci傳輸出錯，io request就應該fail掉，但是，事實不是這樣。難道這個問題和pci的中斷非同步有關係？因此，這裡...
乙個問題記錄2014 10 30
問題背景 公升級所有的動態庫，客戶端獲取不到伺服器資料，並且公升級實際伺服器時沒有備份資料 環境涉及lisp,dll,config 問題查詢過程 1 先在實際伺服器上查詢，看日誌，發現可能是 原因。2 然後在測試伺服器上查詢是否是 的原因，但是發現測試伺服器各種缺必要的資料，也就是說測試伺服器不滿足...