启用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）我根本不知道为什么你要费心使用环回，我个人不知道它会多么接近地模仿真实的界面以及它的有效性如何。我知道 Microsoft 禁用了环回接口的 NAGLE（如果您关心的话）。看看这个链接，有一个关于这个的讨论。

3）我会仔细查看这两种情况下的前几个数据包，看看前五个数据包是否出现严重延迟。看这里