在Linux网络调优方面,如果发现网络流量上不去,那么有一个方面需要检查:网络是否卡被中断以处理网络请求绑定到单个CPU或处理其他中断的同一CPU。网卡与操作系统交互网卡与操作系统交互一般有两种方式:1.中断IRQ网卡收到网络信号后,会主动向CPU发送中断,CPU会立即停止手头的工作是为了响应这个中断信号;2、DMA(DirectMemoryAccess)是让硬件在没有CPU干预的情况下,将数据缓存到指定的内存空间,只有在CPU合适的时候才进行处理;今天的对称多核处理器(SMP上),仍然只有一个CPU响应一块网卡的IRQ,其他CPU无法参与。如果这个CPU忙于其他中断(其他网卡或其他使用中断的外设(如磁盘)),就会形成瓶颈。.检查环境首先,让网络跑满。例如:对于MySQL/MongoDB服务,可以通过客户端发起密集读操作或者进行大文件传输任务。查找某个CPU是否一直忙于处理IRQ?mpstat-PALL1输出中的%irq列显示哪个CPU正忙于处理中断时间;在上面的例子中,第四个CPU有25.63%的时间忙于处理中断,后面的intr/s也显示了CPU每秒处理的中断数。从上面的数据可以看出,其他CPU对中断的处理不是很好。那么,这些忙于处理中断的CPU到底在处理哪些中断呢?这里是每个CPU自启动以来处理的各类中断的数量。第一列是中断号,最后一列是对应的设备名。从上面可以看出eth0发起的中断都是CPU0处理的,CPU0处理的中断请求主要是eth0和LOC中断。有时我们会看到几个CPU处理同一个中断类型的请求数几乎是一样的(比如上面的LOC)。这并不一定意味着多个CPU会轮流处理同一个中断,但由于这里记录的是“自启动以来”的统计数据,可能是因为irqbalancer重新分配了被中断的CPU。解决思路目前的Linux系统大多都有IRQBalance服务(服务程序一般为/usr/sbin/irqbalance),可以自动调整各个中断与CPU的绑定关系,避免所有中断的集中处理中断。在少数CPU上。在某些情况下,这个IRQBalance反而会出问题,irqbalance进程本身会占用更高的CPU(当然也会影响业务系统的性能)。首先我们要看中断是否网卡目前仅限于某些CPU?它们是哪些CPU?根据上面/proc/interrupts的内容,我们可以看到eth0的中断号是74,接下来我们看一下中断号与CPU绑定情况或者叫做affinity亲和力。$sudocat/proc/irq/74/smp_affinityffffff这个输出是16进制的值,0xffffff='0b11111111111111111111111',表示有24个CPU,所有位都为1,表示所有CPU都可以中断干扰。方法修改配置:(设置为2表示绑定中断到CPU1,0x2=0b10,第一个CPU为CPU0)echo2>/proc/irq/74/smp_affinity
