启用 TCP_NODELAY 的 Linux 环回性能

Question

我最近在运行一些比较网络性能与环回性能的性能测试时偶然发现了一个有趣的 TCP 性能问题。在我的例子中，网络性能超过了环回性能(1Gig 网络，相同的子网)。在我处理延迟的情况下，延迟是至关重要的，因此启用了 TCP_NODELAY。我们提出的最佳理论是 TCP 拥塞控制正在阻止数据包。我们做了一些数据包分析，我们可以肯定地看到数据包被保留，但原因并不明显。现在的问题...

1) 在什么情况下，为什么通过环回进行通信会比通过网络进行通信慢？

2) 在尽可能快地发送时，为什么切换 TCP_NODELAY 对通过环回的最大吞吐量的影响比通过网络的影响大得多？

3) 我们如何检测和分析 TCP 拥塞控制作为性能不佳的潜在解释？

4) 有没有人对这种现象的原因有任何其他理论？如果是，有什么方法可以证明这个理论？

这是一个简单的点对点 C++ 应用程序生成的一些示例数据:

Transport     Message Size (bytes)  TCP NoDelay   Send Buffer (bytes)   Sender Host   Receiver Host   Throughput (bytes/sec)  Message Rate (msgs/sec)TCP           128                   On            16777216              HostA         HostB           118085994                922546TCP           128                   Off           16777216              HostA         HostB           118072006                922437TCP           128                   On                4096              HostA         HostB            11097417                 86698TCP           128                   Off               4096              HostA         HostB            62441935                487827TCP           128                   On            16777216              HostA         HostA            20606417                160987TCP           128                   Off           16777216              HostA         HostA           239580949               1871726TCP           128                   On                4096              HostA         HostA            18053364                141041TCP           128                   Off               4096              HostA         HostA           214148304               1673033UnixStream    128                   -             16777216              HostA         HostA            89215454                696995UnixDatagram  128                   -             16777216              HostA         HostA            41275468                322464NamedPipe     128                   -             -                     HostA         HostA            73488749                574130

这里还有一些有用的信息:

• 我只看到这个问题与小留言
• HostA 和 HostB 都具有相同的硬件套件(Xeon X5550@2.67GHz，总共 32 个内核/128 Gig Mem/1Gig Nics)
• 操作系统是 RHEL 5.4 内核 2.6.18-164.2.1.el5)

谢谢

Answer 1

1) 在什么情况下，为什么通过环回通信会比通过网络慢？

Loopback 将 tx+rx 的数据包设置+tcp chksum 计算放在同一台机器上，因此它需要进行 2 倍的处理，而对于 2 台机器，您可以在它们之间拆分 tx/rx。这会对环回产生负面影响。

2) 在尽可能快地发送时，为什么切换 TCP_NODELAY 对通过环回的最大吞吐量的影响比通过网络的影响大得多？

不确定您是如何得出这个结论的，但是环回与网络的实现方式非常不同，如果您尝试将它们推到极限，您会遇到不同的问题。环回接口(interface)(如对 1 的回答中所述)会导致同一台机器上的 tx+rx 处理开销。另一方面，NIC 在循环缓冲区中可以有多少未完成的数据包等方面有# of limits，这将导致完全不同的瓶颈(这在芯片与芯片之间也有很大差异，甚至在交换机之间也有很大差异)他们)

3) 我们如何检测和分析 TCP 拥塞控制作为性能不佳的潜在解释？

拥塞控制只有在丢包时才会启动。你看到丢包了吗？否则，您可能会达到 tcp 窗口大小与网络延迟因素的限制。

4) 有没有人对这种现象的原因有任何其他理论？如果是，有什么方法可以证明这个理论？

我不明白你在这里提到的现象。我在你的表中看到的只是你有一些带有大发送缓冲区的套接字——这可能是完全合法的。在一台快速的机器上，您的应用程序肯定能够生成比网络能够输出的数据更多的数据，所以我不确定您在这里将什么归类为问题。

最后一点:由于各种原因，小消息会对您的网络造成更大的性能影响，例如:

• 每个数据包的开销是固定的(对于 mac+ip+tcp header )，负载越小，开销就越大。
• 许多 NIC 限制都与未完成数据包的数量有关，这意味着当使用较小的数据包时，您将遇到 NIC 瓶颈，而数据会少得多。
• 网络本身作为每个数据包的开销，因此您可以通过网络传输的最大数据量再次取决于数据包的大小。