SMP IRQ Affinity

中断过程简单来说就是一种CPU 与硬件沟通的方式

中断分为两个过程，中间以中断控制器作为分隔。上半部分即中断上半部，下半部分为中断下半部。

上半部分大部分为说说的硬件中断，下半部分为软中断。

硬件中断通常由真实物理设备产生的脉冲信号作为信号源，也就是说这里的物理设备与中断控制器沟通方式是通过物理电信号来做的。

软件中断由中断控制器负责统一调度，通常硬件设备产生信号，这个信号带有中断号发送给中断控制器，中断控制器轮训收到的信号来调用对应的中断处理程序。

直观一点来看：

通过

shell> cat /proc/interrupts 

可以查看到当前系统的软中断列表和对应的中断号

从左到右依次表示：

中断号，对应CPU中断次数，设备类型和设备名

[root@localhost ~]# cat /proc/interrupts 
           CPU0       CPU1       
  0:      14678          0   IO-APIC-edge      timer
  1:          2          0   IO-APIC-edge      i8042
  4:          2          0   IO-APIC-edge    
  7:          0          0   IO-APIC-edge      parport0
  8:          1          0   IO-APIC-edge      rtc0
  9:          0          0   IO-APIC-fasteoi   acpi
 12:          4          0   IO-APIC-edge      i8042
 14:   45394223          0   IO-APIC-edge      ata_piix
 15:          0          0   IO-APIC-edge      ata_piix
 16:         56   16232636   IO-APIC-fasteoi   i915, p2p1
 18:    5333843   11365439   IO-APIC-fasteoi   uhci_hcd:usb4
 20:    2277759          0   IO-APIC-fasteoi   ata_piix
 21:          3          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
 22:          0          0   IO-APIC-fasteoi   uhci_hcd:usb3
 23:       3813       6412   IO-APIC-fasteoi   uhci_hcd:usb5, Intel ICH7
NMI:       1037        925   Non-maskable interrupts
LOC:  319530452  247726622   Local timer interrupts
SPU:          0          0   Spurious interrupts
PMI:       1037        925   Performance monitoring interrupts
PND:          0          0   Performance pending work
RES:     275434     264341   Rescheduling interrupts
CAL:    4975165    5543634   Function call interrupts
TLB:     452039     409944   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
MCE:          0          0   Machine check exceptions
MCP:      14411      14411   Machine check polls
ERR:          0
MIS:          0

APIC表示高级可编程中断控制器（Advanced Programmable Interrupt Controlle）

APIC是SMP体系的核心，通过APIC可以将中断分发到不同的CPU 来处理

比如我这里的0号中断都是由CPU 来处理的，一些其他的中断可以绑定CPU或者可以把中断处理平摊到CPU 上，这个过程叫做 SMP IRQ Affinity

14号中断是属于硬盘设备中断，可以看到中断处理全部由单个CPU完成，这是因为为了使CPU 缓存的命中率提高等因素，使得CPU和硬盘中断绑定（IRQBalance)

如果的多网卡多CPU的情况下，也可以考虑将指定的网卡软中断绑定到对应的CPU 上，这样可以将负载有效的平衡，且能最大限度的利用CPU 缓存。

这样做的前提是先关闭IRQBalance

/etc/init.d/irqbalance stop

然后可以查看到

cat /proc/irq/14/smp_affinity

对应的软中断的多核CPU亲和性设置

我这里显示的是3，是什么意思呢

对应的CPU情况是这样的

CPU0 ----------  00000001     1

CPU1 ----------  00000010     2

CPU2 ----------  00000100     4

.

.

.

CPUN ----------  XXXXXXX     2^N

3 就表示1+2，也就是两个CPU 都均衡，因为开启了IRQ Balance,所以这里中断处理都会交给同一个CPU来保证效率

这里的设置都需要硬件的支持，如果开启关闭IRQBalance自己设置中断处理的CPU亲和，有的设备在负载压力大的时候也是会转到其他CPU处理的，这里的亲和并不是强制性的CPU设置。

亲和性设置建议：DB可以设置一部分CPU处理硬盘IO，一部分CPU处理网络IO，多网卡服务器可以设置对应CPU对应网卡。当然具体情况看生产情况而定

http://www.cnblogs.com/Bozh/archive/2013/01/17/2864201.html

查看IRQ性能

可通过/proc/interrupts查看每个CPU的中断信息；

 

Mpstat输出列包括%irq，而intr/s表示每秒处理的中断数

[oracle@ irq]$ mpstat -P ALL 10

Linux 2.6.32-100.26.2.el5 (.usuwb.astrazeneca.net)   01/31/2013

01:47:50 AM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s

01:48:00 AM  all    1.11    0.00    0.67    0.05    0.00    0.07    0.00   98.10   8696.01

01:48:00 AM    0    0.30    0.00    0.20    0.20    0.00    0.00    0.00   99.30      0.00

01:48:00 AM    1    1.79    0.00    0.99    0.10    0.00    0.00    0.00   97.12      0.10

01:48:00 AM    2    1.10    0.00    1.99    0.00    0.00    0.00    0.00   96.91      0.50

01:48:00 AM    3    1.30    0.00    0.70    0.00    0.00    0.10    0.00   97.90      0.00

01:48:00 AM    4    0.20    0.00    0.10    0.00    0.00    0.00    0.00   99.70      0.00

 

Vmstat中的in代表中断

$ vmstat 1

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st

 4  0    140 2915476 341288 3951700  0    0     0     0 1057  523 19 81  0  0  0

 4  0    140 2915724 341296 3951700  0    0     0     0 1048  546 19 81  0  0  0

 4  0    140 2915848 341296 3951700  0    0     0     0 1044  514 18 82  0  0  0

 4  0    140 2915848 341296 3951700  0    0     0    24 1044  564 20 80  0  0  0

 4  0    140 2915848 341296 3951700  0    0     0     0 1060  546 18 82  0  0  0

从上面的数据可以看出几点：

1. interrupts（in）非常高，context switch（cs）比较低，说明这个 CPU 一直在不停的请求资源；
2. system time（sy）一直保持在 80％ 以上，而且上下文切换较低（cs），说明某个进程可能一直霸占着 CPU（不断请求资源）；
3. run queue（r）刚好在4个。

$ vmstat 1

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st

14  0    140 2904316 341912 3952308  0    0     0   460 1106 9593 36 64  1  0  0

17  0    140 2903492 341912 3951780  0    0     0     0 1037 9614 35 65  1  0  0

20  0    140 2902016 341912 3952000  0    0     0     0 1046 9739 35 64  1  0  0

17  0    140 2903904 341912 3951888  0    0     0    76 1044 9879 37 63  0  0  0

16  0    140 2904580 341912 3952108  0    0     0     0 1055 9808 34 65  1  0  0

从上面的数据可以看出几点：

1. context switch（cs）比 interrupts（in）要高得多，说明内核不得不来回切换进程；
2. 进一步观察发现 system time（sy）很高而 user time（us）很低，而且加上高频度的上下文切换（cs），说明正在运行的应用程序调用了大量的系统调用（system call）；
3. run queue（r）在14个线程以上，按照这个测试机器的硬件配置（四核），应该保持在12个以内。

http://www.vpsee.com/2009/11/linux-system-performance-monitoring-introduction/

http://docs.oracle.com/cd/E24290_01/coh.371/e22838/tune_perftune.htm#CACBAJDB

http://www.vpsee.com/2010/07/load-balancing-with-irq-smp-affinity/