CPU0 被 eth1 中断淹没

Question 1

查看/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，您在重启后仍遇到smp_affinity中断 283 异常，那么您必须在其中一个启动脚本中手动更新 CPU 亲和性。

Answer

查看/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，您在重启后仍遇到smp_affinity中断 283 异常，那么您必须在其中一个启动脚本中手动更新 CPU 亲和性。

Question 2

如果您拥有正确型号的英特尔 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 以太网控制器将中断分配给处理器内核

Answer

如果您拥有正确型号的英特尔 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 以太网控制器将中断分配给处理器内核

Question 3

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

上面链接的来源来自 Linux 研讨会，我建议你阅读一下SMP IRQ 亲和性因为它比这篇文章更能有效地说服你。

为什么？

回想一下，每个处理器除了能够访问主内存外，还有自己的缓存，看看这个图表触发中断时，CPU 核心必须从主内存中获取处理中断的指令，这比指令在缓存中花费的时间要长得多。一旦处理器执行了一项任务，它就会将这些指令保存在缓存中。现在假设同一个 CPU 核心几乎一直处理同一个中断，中断处理程序函数不太可能离开 CPU 核心缓存，从而提高内核性能。

或者，当IRQ平衡时，它可以将中断不断地分配给不同的CPU来处理，那么新的CPU核心很可能在缓存中没有中断处理程序函数，并且需要很长时间才能从主内存中获取适当的处理程序。

例外：如果您很少使用 eth1 中断，这意味着经过足够的时间后缓存会被执行其他任务所覆盖，这意味着您会在较长的时间间隔内间歇性地通过该接口传输数据……那么您很可能不会看到这些好处，因为它们是在您以高频率使用某个进程时产生的。

结论

如果您的中断发生非常通常只需将该中断绑定到特定 CPU 即可。此配置位于

 /proc/'IRQ number'/smp_affinity

或者

/proc/irq/'IRQ number'/smp_affinity

请参阅SMP IRQ 亲和性来自上面链接的来源的部分，它有说明。

或者

您可以通过增加 MTU 大小（巨型帧）来更改中断标志发出的频率（如果网络允许的话），或者更改为在收到大量数据包后而不是每个数据包时都发出标志，或者更改超时时间，以便在一定时间后发出中断。请谨慎使用时间选项，因为您的缓冲区大小可能在时间用完之前就已满。这可以使用ethtool这在链接源中有概述。

这个答案的长度已经接近人们不会阅读的长度，所以我就不赘述了，但根据你的情况，有很多解决方案...请查看来源:)

Answer

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

上面链接的来源来自 Linux 研讨会，我建议你阅读一下SMP IRQ 亲和性因为它比这篇文章更能有效地说服你。

为什么？

回想一下，每个处理器除了能够访问主内存外，还有自己的缓存，看看这个图表触发中断时，CPU 核心必须从主内存中获取处理中断的指令，这比指令在缓存中花费的时间要长得多。一旦处理器执行了一项任务，它就会将这些指令保存在缓存中。现在假设同一个 CPU 核心几乎一直处理同一个中断，中断处理程序函数不太可能离开 CPU 核心缓存，从而提高内核性能。

或者，当IRQ平衡时，它可以将中断不断地分配给不同的CPU来处理，那么新的CPU核心很可能在缓存中没有中断处理程序函数，并且需要很长时间才能从主内存中获取适当的处理程序。

例外：如果您很少使用 eth1 中断，这意味着经过足够的时间后缓存会被执行其他任务所覆盖，这意味着您会在较长的时间间隔内间歇性地通过该接口传输数据……那么您很可能不会看到这些好处，因为它们是在您以高频率使用某个进程时产生的。

结论

如果您的中断发生非常通常只需将该中断绑定到特定 CPU 即可。此配置位于

 /proc/'IRQ number'/smp_affinity

或者

/proc/irq/'IRQ number'/smp_affinity

请参阅SMP IRQ 亲和性来自上面链接的来源的部分，它有说明。

或者

您可以通过增加 MTU 大小（巨型帧）来更改中断标志发出的频率（如果网络允许的话），或者更改为在收到大量数据包后而不是每个数据包时都发出标志，或者更改超时时间，以便在一定时间后发出中断。请谨慎使用时间选项，因为您的缓冲区大小可能在时间用完之前就已满。这可以使用ethtool这在链接源中有概述。

这个答案的长度已经接近人们不会阅读的长度，所以我就不赘述了，但根据你的情况，有很多解决方案...请查看来源:)

CPU0 被 eth1 中断淹没

答案1

答案2

答案3

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

为什么？

结论

或者

相关内容