运行 RHEL 6.10 的 HP ProLiant DL360 G9 出现数据包丢失

Question

检查驱动程序版本。错误rx_no_dma_resources当已满时，正确计算rx buffer。因此，请检查环形缓冲区的长度（ethtool -g <iface>）并增加它（ethtool -G <iface> rx <size> tx <size>，但这会导致数据包处理出现短暂中断）。

笔记：问题更新后，您知道没有错误，但我认为应该按重要性顺序解决问题。因此，让我们先解决有missing错误的问题，然后再尝试解决rx_no_dma_resources错误。

这rx_missed_errors意味着系统没有足够的 CPU 资源来处理传入的数据包。在大多数情况下，当应该执行 irq 处理程序的 CPU 核心处于负载下时，就会发生这种情况。检查命令的输出cat /proc/interrupts。调查 NIC irq 计数器在 CPU 核心之间的分布情况。禁用irqbalance并使用set_irq_affinity脚本将 irq 处理程序绑定到核心。如果您的系统有多个 NUMA 域，您应该使用此脚本的local或选项。remote
检查命令的输出perf top来调查是什么原因导致网络数据包处理时的 CPU 负载。

更新 1

如您在中看到的/proc/interrupts，一些 CPU 核心（15、18、19）处理来自eth6-TxRx-6队列 irq 处理程序的中断比其他核心多得多（数百倍）。检查这些 CPU 核心的负载。很可能，它们经常处于过载状态。

因此，除了不正确的 CPU 亲和性和之外irqbalance，您还有其他问题。您应该调查通过eth6NIC 队列 6 的主要流量类型。使用交换机端口镜像和 wireshark（从开始Statistics - Protocol Hierarchy）。之后，您可以使用调整 RSS 哈希以ethtool在多个 NIC 队列之间共享此流量。这将避免某些核心过载。

关于 NUMA 的一些说明

您询问了有关脚本的详细信息local和remote选项set_irq_affinity。为了回答这个问题，我绘制了双插槽系统的简化图。

现代 CPU 具有集成内存控制器和 PCI-express 控制器。在多插槽系统中，存在一个处理器间链路，用于在处理器之间进行数据交换。每个处理器都可以访问所有内存。但是，如果一个处理器使用由另一个处理器的内存控制器管理的内存区域中的数据，则需要向该远程内存控制器请求开销，并需要对处理器间链路上的数据传输进行惩罚。

PCI-Express 设备和系统之间的数据传输通过 DMA（直接内存访问）实现，这使得外围设备无需向 CPU 发出明确请求即可将数据读取/写入 RAM。显然，这是非常具体的实现，但它也继承了相同的内存访问限制。

那么，irq affinity 是如何参与其中的呢？大致来说，当 PCI-Express NIC 从外部接收到数据时，它会使用 DMA 将该数据存储在系统 RAM 中，并生成中断以通知系统。如果中断处理程序将在另一个 CPU 上执行，而不是在本地执行，会发生什么情况？当然，中断处理程序需要接收到的数据来处理它。并且将获得远程内存的所有开销和惩罚。在最坏的情况下，它可能导致处理器间链路过载。

因此，如您所见，正确设置 NUMA 系统的 irq 亲和性非常重要。该set_irq_affinity脚本会自动将 NIC 队列 irq 处理程序绑定到 CPU 核心。在最佳情况下，您将在中看到非零计数器的“阶梯” /proc/interrupts。显然，irqbalance试图玩自己的游戏并完全消除此 irq 亲和性带来的好处。

更新 2

那么，我们目前掌握的信息是：

eth6-TxRx-6有大量的多播流量，由中断处理程序处理。
UDP4:ip source address和的 RSS 哈希ip destination address。
运行后，set_irq_affinity此队列的处理程序绑定到第 16 个核心。

您现在可以做什么：

监控统计数据和核心负载，特别是第 16 个核心。是否还存在过载和缺失错误？
此多播流量是唯一一个流还是多个流？如果存在多个流，您可以使用调整的哈希值udp4。ethtool如果 NIC 不仅使用 IP 地址进行哈希值计算，还使用和端口号，则它可能能够在多个接收队列之间共享处理，从而在多个 CPU 核心之间共享处理。如果这是唯一的一个流，那么您可以尝试将更多 CPU 核心绑定到相应的 irq 处理程序。

更新 3

因此，您同时遇到了几个问题。

在netstat输出中您有：

1264898431 数据包接收错误

但这些错误与丢失错误无关。当系统没有足够的 CPU 资源来处理中断时，数据包将在执行任何协议处理程序之前丢失。如果 UDP 套接字缓冲区的内存不足，您将在命令的输出中看到相应的错误nstat -az UdpRcvbufErrors。监视它并使用 sysctl 变量增加内存限制。您还可以使用工具监视套接字的接收队列ss。这也很有帮助。

调查哪些进程消耗了 CPU 时间。之后，您可以使用perf record或分析工作负载perf top。它真的softirq使单核过载吗？这个内核进程维护着很多东西，因此perf top调查到底是什么消耗了最多的 CPU 时间会很有帮助。
如果您只有一个多播组，则此流将只执行单个 irq，因为 n-tuple-hash 将始终相同。我不知道这种情况有什么解决方法。唯一的方法是使用更快的处理器。您还可以检查i7z工具的结果以监视 CPU 的睡眠状态。
我不知道您的应用程序架构细节，但当运行多个实例时，您可能也遇到了多播 UDP 数据报丢失的问题。也许这也与应用程序实例与 CPU 核心的错误绑定有关。尝试将应用程序进程绑定到 CPU 核心。

附言当您提供有关上述步骤的结果的信息时，我会扩展答案。

Answer 1

检查驱动程序版本。错误rx_no_dma_resources当已满时，正确计算rx buffer。因此，请检查环形缓冲区的长度（ethtool -g <iface>）并增加它（ethtool -G <iface> rx <size> tx <size>，但这会导致数据包处理出现短暂中断）。

笔记：问题更新后，您知道没有错误，但我认为应该按重要性顺序解决问题。因此，让我们先解决有missing错误的问题，然后再尝试解决rx_no_dma_resources错误。

这rx_missed_errors意味着系统没有足够的 CPU 资源来处理传入的数据包。在大多数情况下，当应该执行 irq 处理程序的 CPU 核心处于负载下时，就会发生这种情况。检查命令的输出cat /proc/interrupts。调查 NIC irq 计数器在 CPU 核心之间的分布情况。禁用irqbalance并使用set_irq_affinity脚本将 irq 处理程序绑定到核心。如果您的系统有多个 NUMA 域，您应该使用此脚本的local或选项。remote
检查命令的输出perf top来调查是什么原因导致网络数据包处理时的 CPU 负载。

更新 1

如您在中看到的/proc/interrupts，一些 CPU 核心（15、18、19）处理来自eth6-TxRx-6队列 irq 处理程序的中断比其他核心多得多（数百倍）。检查这些 CPU 核心的负载。很可能，它们经常处于过载状态。

因此，除了不正确的 CPU 亲和性和之外irqbalance，您还有其他问题。您应该调查通过eth6NIC 队列 6 的主要流量类型。使用交换机端口镜像和 wireshark（从开始Statistics - Protocol Hierarchy）。之后，您可以使用调整 RSS 哈希以ethtool在多个 NIC 队列之间共享此流量。这将避免某些核心过载。

关于 NUMA 的一些说明

您询问了有关脚本的详细信息local和remote选项set_irq_affinity。为了回答这个问题，我绘制了双插槽系统的简化图。

现代 CPU 具有集成内存控制器和 PCI-express 控制器。在多插槽系统中，存在一个处理器间链路，用于在处理器之间进行数据交换。每个处理器都可以访问所有内存。但是，如果一个处理器使用由另一个处理器的内存控制器管理的内存区域中的数据，则需要向该远程内存控制器请求开销，并需要对处理器间链路上的数据传输进行惩罚。

PCI-Express 设备和系统之间的数据传输通过 DMA（直接内存访问）实现，这使得外围设备无需向 CPU 发出明确请求即可将数据读取/写入 RAM。显然，这是非常具体的实现，但它也继承了相同的内存访问限制。

那么，irq affinity 是如何参与其中的呢？大致来说，当 PCI-Express NIC 从外部接收到数据时，它会使用 DMA 将该数据存储在系统 RAM 中，并生成中断以通知系统。如果中断处理程序将在另一个 CPU 上执行，而不是在本地执行，会发生什么情况？当然，中断处理程序需要接收到的数据来处理它。并且将获得远程内存的所有开销和惩罚。在最坏的情况下，它可能导致处理器间链路过载。

因此，如您所见，正确设置 NUMA 系统的 irq 亲和性非常重要。该set_irq_affinity脚本会自动将 NIC 队列 irq 处理程序绑定到 CPU 核心。在最佳情况下，您将在中看到非零计数器的“阶梯” /proc/interrupts。显然，irqbalance试图玩自己的游戏并完全消除此 irq 亲和性带来的好处。

更新 2

那么，我们目前掌握的信息是：

eth6-TxRx-6有大量的多播流量，由中断处理程序处理。
UDP4:ip source address和的 RSS 哈希ip destination address。
运行后，set_irq_affinity此队列的处理程序绑定到第 16 个核心。

您现在可以做什么：

监控统计数据和核心负载，特别是第 16 个核心。是否还存在过载和缺失错误？
此多播流量是唯一一个流还是多个流？如果存在多个流，您可以使用调整的哈希值udp4。ethtool如果 NIC 不仅使用 IP 地址进行哈希值计算，还使用和端口号，则它可能能够在多个接收队列之间共享处理，从而在多个 CPU 核心之间共享处理。如果这是唯一的一个流，那么您可以尝试将更多 CPU 核心绑定到相应的 irq 处理程序。

更新 3

因此，您同时遇到了几个问题。

在netstat输出中您有：

1264898431 数据包接收错误

但这些错误与丢失错误无关。当系统没有足够的 CPU 资源来处理中断时，数据包将在执行任何协议处理程序之前丢失。如果 UDP 套接字缓冲区的内存不足，您将在命令的输出中看到相应的错误nstat -az UdpRcvbufErrors。监视它并使用 sysctl 变量增加内存限制。您还可以使用工具监视套接字的接收队列ss。这也很有帮助。

调查哪些进程消耗了 CPU 时间。之后，您可以使用perf record或分析工作负载perf top。它真的softirq使单核过载吗？这个内核进程维护着很多东西，因此perf top调查到底是什么消耗了最多的 CPU 时间会很有帮助。
如果您只有一个多播组，则此流将只执行单个 irq，因为 n-tuple-hash 将始终相同。我不知道这种情况有什么解决方法。唯一的方法是使用更快的处理器。您还可以检查i7z工具的结果以监视 CPU 的睡眠状态。
我不知道您的应用程序架构细节，但当运行多个实例时，您可能也遇到了多播 UDP 数据报丢失的问题。也许这也与应用程序实例与 CPU 核心的错误绑定有关。尝试将应用程序进程绑定到 CPU 核心。

附言当您提供有关上述步骤的结果的信息时，我会扩展答案。

运行 RHEL 6.10 的 HP ProLiant DL360 G9 出现数据包丢失

更新 1

更新 2

更新 3

答案1

更新 1

关于 NUMA 的一些说明

更新 2

更新 3

相关内容