CPU0被eth1中断淹没

我有一个在基于Ubuntu的Xen XCP内运行的Ubuntu VM。它在后面托管了一个基于FCGI的自定义HTTP服务nginx。

来自第一个CPU内核的负载ab 不足已达到饱和，其余的负载不足。

在/proc/interrupts我看到CPU0供应数量级的中断比任何其他核心订单。他们大多数来自eth1。

我可以做些什么来改善此VM的性能？有没有办法更均匀地平衡中断？

血腥细节：

$ uname -a
Linux MYHOST 2.6.38-15-虚拟＃59-Ubuntu SMP Fri Apr 27 16:40:18 UTC 2012 i686 i686 i386 GNU / Linux

$ lsb_release -a
没有可用的LSB模块。
发行人ID：Ubuntu
说明：Ubuntu 11.04
发行：11.04
代号：natty

$ cat / proc / interrupts 
           CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7       
283：113720624 0 0 0 0 0 0 0 xen-dyn-event eth1
284：1 0 0 0 0 0 0 0 xen-dyn-event eth0
285：2254 0 0 3873799 0 0 0 0 xen-dyn-event blkif
286：23 0 0 0 0 0 0 0 xen-dyn-event hvc_console
287：492 42 0 0 0 0 0 295324 xen-dyn-event xenbus
288：0 0 0 0 0 0 0 222294 xen-percpu-ipi callfuncsingle7
289：0 0 0 0 0 0 0 0 xen-percpu-virq debug7
290：0 0 0 0 0 0 0 151302 xen-percpu-ipi callfunc7
291：0 0 0 0 0 0 0 3236015 xen-percpu-ipi resched7
292：0 0 0 0 0 0 0 60064 xen-percpu-ipi spinlock7
293：0 0 0 0 0 0 0 12355510 xen-percpu-virq计时器7
294：0 0 0 0 0 0 803174 0 xen-percpu-ipi callfuncsingle6
295：0 0 0 0 0 0 0 0 xen-percpu-virq debug6
296：0 0 0 0 0 0 60027 0 xen-percpu-ipi callfunc6
297：0 0 0 0 0 0 5374762 0 xen-percpu-ipi resched6
298：0 0 0 0 0 0 64976 0 xen-percpu-ipi spinlock6
299：0 0 0 0 0 0 15294870 0 xen-percpu-virq timer6
300：0 0 0 0 0 264441 0 0 xen-percpu-ipi callfuncsingle5
301：0 0 0 0 0 0 0 0 xen-percpu-virq debug5
302：0 0 0 0 0 79324 0 0 xen-percpu-ipi callfunc5
303：0 0 0 0 0 3468144 0 0 xen-percpu-ipi resched5
304：0 0 0 0 0 66269 0 0 xen-percpu-ipi spinlock5
305：0 0 0 0 0 12778464 0 0 xen-percpu-virq timer5
306：0 0 0 0 844591 0 0 0 xen-percpu-ipi callfuncsingle4
307：0 0 0 0 0 0 0 0 xen-percpu-virq debug4
308：0 0 0 0 75293 0 0 0 xen-percpu-ipi callfunc4
309：0 0 0 0 3482146 0 0 0 xen-percpu-ipi resched4
310：0 0 0 0 79312 0 0 0 xen-percpu-ipi spinlock4
311：0 0 0 0 21642424 0 0 0 xen-percpu-virq timer4
312：0 0 0 449141 0 0 0 0 xen-percpu-ipi callfuncsingle3
313：0 0 0 0 0 0 0 0 xen-percpu-virq debug3
314：0 0 0 95405 0 0 0 0 xen-percpu-ipi callfunc3
315：0 0 0 3802992 0 0 0 0 xen-percpu-ipi resched3
316：0 0 0 76607 0 0 0 0 xen-percpu-ipi spinlock3
317：0 0 0 16439729 0 0 0 0 xen-percpu-virq timer3
318：0 0 876383 0 0 0 0 0 xen-percpu-ipi callfuncsingle2
319：0 0 0 0 0 0 0 0 xen-percpu-virq debug2
320：0 0 76416 0 0 0 0 0 xen-percpu-ipi callfunc2
321：0 0 3422476 0 0 0 0 0 xen-percpu-ipi resched2
322：0 0 69217 0 0 0 0 0 xen-percpu-ipi spinlock2
323：0 0 10247182 0 0 0 0 0 xen-percpu-virq timer2
324：0 393514 0 0 0 0 0 0 xen-percpu-ipi callfuncsingle1
325：0 0 0 0 0 0 0 0 xen-percpu-virq debug1
326：0 95773 0 0 0 0 0 0 xen-percpu-ipi callfunc1
327：0 3551629 0 0 0 0 0 0 xen-percpu-ipi resched1
328：0 77823 0 0 0 0 0 0 xen-percpu-ipi spinlock1
329：0 13784021 0 0 0 0 0 0 xen-percpu-virq timer1
330：730435 0 0 0 0 0 0 0 xen-percpu-ipi callfuncsingle0
331：0 0 0 0 0 0 0 0 xen-percpu-virq debug0
332：39649 0 0 0 0 0 0 0 xen-percpu-ipi callfunc0
333：3607120 0 0 0 0 0 0 0 xen-percpu-ipi resched0
334：348740 0 0 0 0 0 0 0 xen-percpu-ipi spinlock0
335：89912004 0 0 0 0 0 0 0 xen-percpu-virq计时器0
NMI：0 0 0 0 0 0 0 0不可屏蔽中断
LOC：0 0 0 0 0 0 0 0本地定时器中断
SPU：0 0 0 0 0 0 0 0虚假中断
PMI：0 0 0 0 0 0 0 0性能监视中断
IWI：0 0 0 0 0 0 0 0 IRQ工作中断
RES：3607120 3551629 3422476 3802992 3482146 3468144 5374762 3236015重新安排中断
CAL：770084 489287 952799 544546 919884 343765 863201 373596函数调用中断
TLB：0 0 0 0 0 0 0 0 TLB击落
TRM：0 0 0 0 0 0 0 0热事件中断
THR：0 0 0 0 0 0 0 0阈值APIC中断
MCE：0 0 0 0 0 0 0 0机器检查异常
MCP：0 0 0 0 0 0 0 0机器检查轮询
错误：0
MIS：0

在/proc/irq/283目录中查找。有一个smp_affinity_list文件显示哪个CPU将获得283中断。对于您来说，该文件可能包含“ 0”（并且smp_affinity可能包含“ 1”）。

您可以将CPU范围写入smp_affinity_list文件：

echo 0-7 | sudo tee /proc/irq/283/smp_affinity_list

或者，您也可以编写一个位掩码，其中每个位对应一个CPU smp_affinity：

printf %x $((2**8-1)) | sudo tee /proc/irq/283/smp_affinity

但是，已知irqbalance对每个中断应具有的亲和力有自己的想法，并且它可能会还原您的更新。因此，最好是完全卸载irqbalance。或者至少将其停止，并使其在重新启动时无法启动。

如果即使没有irqbalance，smp_affinity重新启动后也会对283中断感到奇怪，则必须在其中一个启动脚本中手动更新CPU亲和力。

如果您具有正确的Intel NIC型号，则可以显着提高性能。

引用第一段：

多核处理器和最新的以太网适配器（包括82575、82576、82598和82599）可通过将执行流分配给各个内核来优化TCP转发流。默认情况下，Linux自动将中断分配给处理器内核。当前存在两种用于自动分配中断的方法，即用户空间中的内核IRQ平衡器和IRQ平衡守护程序。两者都提供了可能会降低CPU使用率但无法最大化IP转发速率的折衷方案。通过手动将以太网适配器的队列固定到特定处理器内核，可以获得最佳吞吐量。

对于IP转发，发送/接收队列对应使用相同的处理器内核，并减少不同内核之间的任何高速缓存同步。这可以通过将发送和接收中断分配给特定内核来执行。从Linux内核2.6.27开始，可以在82575、82576、82598和82599上使用多个队列。此外，在扩展消息传递信号中断（MSI-X）中启用了多个发送队列。MSI-X支持可以使用的大量中断，从而可以对中断进行更细粒度的控制并将中断定向到特定的CPU。

请参阅：使用英特尔®82575/82576或82598/82599以太网控制器将中断分配给处理器内核

实际上，特别是在短时间内处理重复进程时，建议由设备队列生成的所有中断均由同一CPU处理，而不是由IRQ平衡处理，因此，如果单个CPU处理eth1中断，您将看到更好的性能。 ***以下提供例外

上面链接的资源来自Linux Symposium，我建议您通读SMP IRQ Affinity上的几段内容，因为它比本文更有效地说服您。

为什么？

回忆每个处理器除了可以访问主存储器外还有自己的缓存，请查看此图。触发中断时，CPU内核将必须从主内存中获取指令以处理中断，这比指令在高速缓存中的位置要花费更长的时间。一旦处理器执行了任务，它将在高速缓存中具有这些指令。现在说相同的CPU内核几乎始终处理相同的中断，中断处理程序函数将不太可能离开CPU内核缓存，从而提高了内核性能。

另外，当IRQ处于平衡状态时，它可以分配要由其他CPU不断处理的中断，那么新的CPU内核可能在高速缓存中将不具有中断处理程序功能，并且需要很长时间才能从主处理器获取正确的处理程序。记忆。

例外：如果您很少使用eth1中断，则意味着经过了足够的时间以致通过执行其他任务来覆盖高速缓存，这意味着您有间歇性地通过该接口的数据间歇性地经过该接口，那么您很可能看不到这些好处因为它们是在您频繁使用过程时。

结论

如果您的中断非常频繁地发生，则只需将该中断绑定到仅由特定的CPU处理即可。此配置位于

 /proc/'IRQ number'/smp_affinity

要么

/proc/irq/'IRQ number'/smp_affinity

请参阅上面链接的源中的SMP IRQ Affinity部分中的最后一段，其中有说明。

或者

您可以通过增加MTU大小（巨型帧）（如果网络允许）来更改产生中断标志的频率，或者在接收到更多的数据包之后而不是在每个数据包处更改使标志产生的标志，或者更改超时，因此在一定时间后引发中断。使用time选项时要小心，因为在时间用完之前缓冲区的大小可能已满。可以使用链接源中概述的ethtool来完成。

这个答案正在接近人们不会读的长度，因此我将不做详细介绍，但是根据您的情况，有很多解决方案...请查看源代码:)