tcpdump提高udp性能

我正在运行一组负载测试以确定以下设置的性能：

Node.js test suite (client) --> StatsD (server) --> Graphite (server)

简而言之，node.js测试套件每隔x秒就会向另一台服务器上的StatsD实例发送一定数量的指标。然后，StatsD每秒将指标刷新到位于同一服务器上的Graphite实例。然后，我查看测试套件实际发送了多少度量，以及Graphite收到了多少度量，以确定测试套件与Graphite之间的数据包丢失。

但是我注意到有时我会有非常大的丢包率（注意它是通过UDP协议发送的），范围从20％到50％。因此，当我开始查看这些数据包的丢弃位置时，发现StatsD可能是一些性能问题。因此，我开始记录系统各个部分的指标，以跟踪发生此下降的位置。这就是事情变得奇怪的地方。

我正在使用tcpdump创建一个捕获文件，在测试运行完成后检查该文件。但是每当我在运行tcpdump的情况下运行测试时，几乎都不存在数据包丢失的情况！看起来tcpdump某种程度上提高了我的测试性能，但我不知道为什么以及如何做到这一点。我正在运行以下命令来在服务器和客户端上记录tcpdump消息：

tcpdump -i any -n port 8125 -w test.cap

在一个特定的测试案例中，我正在发送40000个指标/秒。运行tcpdump时的测试的数据包丢失率约为4％，而没有进行测试的数据包丢失率约为20％

这两个系统均通过以下设置作为Xen VM运行：

• 英特尔至强E5-2630 v2 @ 2.60GHz
• 2GB RAM
• Ubuntu 14.04 x86_64

我已经检查过的潜在原因：

• 增加UDP缓冲区的接收/发送大小。
• 影响测试的CPU负载。（客户端和服务器端的最大负载为40-50％）
• 在特定接口而不是“ any”上运行tcpdump。
• 使用'-p'运行tcpdump以禁用混杂模式。
• 仅在服务器上运行tcpdump。这导致发生20％的数据包丢失，并且似乎不影响测试。
• 仅在客户端上运行tcpdump。这样可以提高性能。
• 将netdev_max_backlog和netdev_budget增加到2 ^ 32-1。这没什么区别。
• 在每个nic上尝试了混杂模式的所有可能设置（服务器打开和客户端关闭，服务器关闭和客户端打开，都打开，都关闭）。这没什么区别。

当tcpdump运行时，在读入帧时会非常提示。我的假设是，NIC的数据包环形缓冲区设置可能很小。当tcpdump运行时，它会更及时地清空。

如果您是Red Hat订户，那么此支持文章对数据包接收概述非常有用。我那里还有些东西我还没有考虑过。

考虑您的系统如何处理IRQ；考虑增加网络接口的“ dev_weight”（意味着更多的数据包将从NIC读取到用户空间）；查看应用程序读取套接字的频率（它是否可以使用专用线程，是否存在有关可伸缩性的已知问题/解决方法）。

增加NIC帧缓冲区（使用ethtool命令-查看--set-ringetc等参数）。

查看“接收方扩展”，并至少使用那么多接收线程来读取流量。

我不知道tcpdump是否在做一些很棒的事情，例如使用内核对数据包环形缓冲区的支持。这将有助于解释您所看到的行为。

您正在使用什么电源调速器？我已经看到“按需”或“保守”调速器的类似行为。

尝试使用“性能”调节器并禁用服务器BIOS中的所有节能功能。

它会改变某些东西吗？

另一种方法是ip_conntarck模块，您确定您的linux-box可以接受新连接吗？通过测试：

root@debian:/home/mohsen# sysctl net.ipv4.netfilter.ip_conntrack_max
net.ipv4.netfilter.ip_conntrack_max = 65536
root@debian:/home/mohsen# sysctl  net.ipv4.netfilter.ip_conntrack_count
net.ipv4.netfilter.ip_conntrack_count = 29

你必须测试

net.ipv4.netfilter.ip_conntrack_max >  net.ipv4.netfilter.ip_conntrack_count

如果max == count，则最大连接已满，并且linux-box无法接受新连接。
如果您没有ip_conntrack，则可以通过以下方式轻松加载modprobe ip_conntrack

我怀疑接收方根本无法处理数据包速率，原因如下：

1. 在客户端上使用tcpdump 减少了丢弃的数据包：tcpdump减慢了客户端的速度，因此服务器看到的打包机速率要低得多，它仍然可以部分处理。您应该能够通过检查客户端和服务器上的RX / TX数据包计数器来确认此假设

2. 您提到增加了UDP缓冲区的接收/发送大小，能否详细说明如何？重要的是，在服务器上同时更改rmem_max 和 rmem_default，例如： sysctl -w net.core.rmem_max=524287 sysctl -w net.core.wmem_max=524287 sysctl -w net.core.rmem_default=524287 sysctl -w net.core.wmem_default=524287

测试您的设置

停止statsd和节点应用程序，然后在系统空闲时使用iperf测试网络/内核可以处理的数据包速率。如果您可以使用iperf传输40K数据包/秒，但不能使用statsd传输，那么您应该集中精力调整statsd。

其他可调项

还请记住调整net.core.netdev_max_backlog：当特定接口接收数据包的速度快于内核处理数据包的速度时，允许排队的最大数据包数。