为什么巨型帧会影响服务器的性能

更新:我应该只设置巨型帧到服务器和文件服务器,而不是客户端?

如果是这样,服务器和客户端之间的通信是否有影响?


我正在对我们的产品进行一些性能testing。

目前,所有与testing相关的机器(服务器,文件服务器,客户端,数据库)均位于由强大的Dell OpenManage交换机连接的10Gnetworking上。

我们使用iscsi作为文件服务器。 我们有一个包含多个节点的集群服务器。

我正在运行的性能testing基本上是模拟以下情况:1.客户机将创build大量的线程向服务器发送http请求。 2.根据不同types的请求,服务器需要从所有其他服务器节点共享的文件服务器获取一些数据。

testing结果是:没有巨型帧,MTU 1500,服务器CPU 70%,http请求的平均响应时间是1秒。

对于巨型帧,MTU 9000,服务器CPU 20%,http请求的平均响应时间为5秒。

我们在所有机器上configuration了巨型帧,并更改了TCP设置。

有任何想法吗?

好:

  • 更大的帧数=每个包上的数据量越多=您的CPU发送数据的工作量越less(每秒数据包数量越less),但组装每个有效负载需要更长的时间(更多延迟)。
  • 更小的帧=每个包上的数据越less=你的cpu的工作原理是发送数据(每秒更多的包),但是组装每个有效负载所需的时间更less(延迟更less)。

我一直在努力阅读和理解更多关于使用巨型帧的影响,以及为什么在十多年后还没有成为主stream。 本文提出了巨型帧尺寸所面临的现实世界问题,阻止它实现超过批量文件传输的情况。

http://www.chelsio.com/jumbo_enet_frames.html

导致高延迟延迟的问题总结

  1. 延迟传输介质间的stream水线
  2. 小的发送/接收缓冲区导致丢包=重传
  3. 较大的数据包大小=较高的冲突几率=重传
  4. 在有效负载长度更低的情况下降低CRC质量=损坏的数据包=重传
  5. 端到端pathMTU发现,两种方式

你的“服务器”应该有一个iSCSI接口(这个接口是磁盘总线!),还有一个客户端访问服务器的接口。 iSCSI接口应该是MTU9000,客户端访问接口应该有一个默认的MTU。 另外,您的交换机需要configuration为支持巨型帧和stream量控制,否则性能会下降。