服务器 Gind.cn
  1. 服务器 Gind.cn
  3. tcpdump增加udp性能
Intereting Posts
在ssh上使用rsync时，如何指定相对于用户主目录的path build立一个Virutal电脑，并把它作为一个DC 有没有办法将networking文件系统（SMB 2.0）的索引存储在服务器上，以便我的用户不必手动设置索引？ 与非透明代理相比，透明代理是否有局限性？ 帐户策略的组策略设置消失 用DSL网关设置DD-WRT路由器时遇到困难 自动化的Linux部署和小规模的configurationpipe理 – 值得吗？ ioncube安装centos 6 zend错误 我可以在LXC容器中使用不同的Linux发行版吗？ 导出与备份 squidGuard在安装过程中挂起 如何在Linux中findANT_HOME的正确path？ Ubuntu自定义服务器一段时间后：连接重置由对等 Server 2008漫游configuration文件权限 closures现货Amazon EC2实例是否清洁？

tcpdump增加udp性能

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

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

简而言之，node.jstesting套件每隔x秒向一个位于另一个服务器上的StatsD实例发送一组量度的指标。 然后，StatsD每秒钟将指标刷新到位于同一台服务器上的Graphite实例。 然后我看看testing套件实际发送了多less指标，以及Graphite收到了多less指标，以确定testing套件与Graphite之间的数据包丢失情况。

但是我注意到，我有时会得到非常大的数据包丢失率（请注意，它是使用UDP协议发送的），从20％到50％不等。 那么当我开始研究这些数据包被丢弃的位置时，就会发现StatsD可能会带来一些性能问题。 于是我开始在系统的每个部分logging指标来追踪这个下降发生的地方。 这是事情变得怪异的地方。

我正在使用tcpdump来创build一个捕获文件，我testing完成后运行。 但是每当我运行tcpdump运行testing，数据包丢失几乎是不存在的！ 它看起来像tcpdump以某种方式增加我的testing的性能，我不明白为什么以及如何做到这一点。 我正在运行以下命令在服务器和客户端上loggingtcpdump消息： 

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

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

两个系统都以Xen VM的forms运行，具有以下设置：

  • Intel Xeon E5-2630 v2 @ 2.60GHz
  • 2GB内存
  • Ubuntu 14.04 x86_64

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

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

当tcpdump正在运行时，在读取传入帧时会相当及时。 我的假设是，NIC的数据包环缓冲区设置可能有点小尺寸; 当tcpdump正在运行时，它会被更及时地清空。

如果你是一个红帽订户，那么这个支持文章是非常有用的数据包接收概述 。 它有一些东西，我不认为你已经考虑过了。

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

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

看看“接收方缩放”，并使用至less很多接收线程来读取stream量。

我不知道是否tcpdump正在做一些很酷的事情，比如使用内核支持包环缓冲区 。 这将有助于解释你所看到的行为。

你用什么权力调控？ 我见过类似的行为与“省”或“保守”州长。

尝试使用“性能”pipe理器并禁用服务器BIOS中的任何省电function。

它会改变什么吗？

另一种方式是ip_conntarck模块，你确定你的linux-box可以接受新的连接吗？ testing通过： 

 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

你必须testing 

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

如果max == count，你的最大连接是满的，你的linux-box不能接受新的连接。
如果您没有ip_conntrack，则可以通过modprobe ip_conntrack轻松modprobe ip_conntrack

我怀疑接收方根本无法处理数据包速率，这是为什么：

  1. 在客户端上使用tcpdump可以减less数据包丢失：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

testing你的设置

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

其他可调参数

还要记住调整net.core.netdev_max_backlog ：当特定接口接收数据包的速度超过内核可以处理的最大数量的数据包。