启用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                922546
TCP           128                   Off           16777216              HostA         HostB           118072006                922437
TCP           128                   On                4096              HostA         HostB            11097417                 86698
TCP           128                   Off               4096              HostA         HostB            62441935                487827
TCP           128                   On            16777216              HostA         HostA            20606417                160987
TCP           128                   Off           16777216              HostA         HostA           239580949               1871726
TCP           128                   On                4096              HostA         HostA            18053364                141041
TCP           128                   Off               4096              HostA         HostA           214148304               1673033
UnixStream    128                   -             16777216              HostA         HostA            89215454                696995
UnixDatagram  128                   -             16777216              HostA         HostA            41275468                322464
NamedPipe     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 对环回的最大吞吐量的影响要大于对网络的影响？

不确定你是如何得出这个结论的，但环回vs网络的实现方式却截然不同，如果你试图将它们推到极限，你就会遇到不同的问题。环回接口（如回答1所述）导致同一台机器上的tx + rx处理开销。另一方面，NIC在其循环缓冲区等中可以拥有多少个未完成的数据包，这将导致完全不同的瓶颈（并且这在芯片之间也会有很大差异，甚至来自两者之间的交换机）它们）

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

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

4）有没有人对这种现象的原因有任何其他理论？如果是的话，任何证明该理论的方法都可以吗？

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

最后一点：由于各种原因，小消息会在您的网络上产生更大的性能影响，例如：

• 每个数据包开销有一个固定的（对于mac + ip + tcp标头），有效负载越小，你的开销就越大。
• 许多NIC限制都与未完成的数据包相关，这意味着当使用较小的数据包时，您将使用更少的数据来克服NIC瓶颈。
• 网络本身作为每个数据包开销，因此您可以通过网络泵送的最大数据量再次取决于数据包的大小。

Answer 2

1或2）我不确定你为什么要打扰使用环回，我个人不知道它会模仿一个真实的接口有多紧密以及它将如何有效。我知道微软会为环回接口禁用NAGLE（如果你愿意的话）。看看this link，有关于此的讨论。

3）我会密切关注两种情况下的前几个数据包，看看你是否在前五个数据包中遇到严重延迟。见here

Answer 3

这也是我面临的同样问题。在同一台RHEL6机器上运行的两个组件之间传输2 MB数据时，需要7秒才能完成。当数据大小很大时，时间是不可接受的。传输10 MB数据需要1分钟。

然后我尝试禁用TCP_NODELAY。它解决了这个问题

当两个组件位于两台不同的机器中时，不会发生这种情况。