我有一个困扰我的问题，因为有一段时间了。 我有几个环境和服务器。 所有这些都连接到1千兆位以太网swiches（例如思科3560）。
我的理解是，1千兆位的链路应该提供125Mbyte / s – 当然这是理论。 但至less应该达到〜100Mbyte / s。
这里的问题是，一个复制过程只能达到〜20Mbyte / s。
我知道这些因素，但他们没有任何区别：
所有这些configuration，我从来没有得到超过〜25Mbyte / s的吞吐量。 事情是，如果我启动多个并行复制stream，比如rsync的3倍，我几乎达到了90Mbyte / s。 我也做了一些IOMetertesting，发现“chunksize”有很大的不同，但通常不能用给定的工具调整（或者是？）。
巨型框架没有启用，但我不确定是否会有所作为。 TOE在所有NIC上启用。
你会想到什么瓶颈？ 你有类似的经历吗？ 这些是预期的“自然”价值吗？
提前致谢
如果这些都是按照stream的方式进行的，那么你就会遇到“带宽延迟产品”的问题。 基本上，在任何一个时间（在TCP中，这是“窗口大小”）有多less数据将“在飞行中”是有限制的，并且对于给定的往返延迟，您不能超过一定数量的数据，因为发件人必须等待收件人确认收到已发送的数据，才能发送更多的数据。 粗略地说，你的TCP吞吐量将是窗口大小/往返延迟（以秒为单位）。
这不仅仅是一个TCP的东西（尽pipe我使用这个例子是因为如果你想进一步寻找这个例子，那么这个例子就是那个文献最多的）。 在发送更多数据之前等待确认的所有协议都会遭遇同样的问题。 从理论上讲，你可以发送所有的数据，而不是等待哎呀，但是这通常被认为是一件坏事，因为你可以“淹没”接收者而不给他们任何方式来阻止stream水。
对于大多数协议，您可以调整窗口大小，以便您可以同时有更多的数据“在飞行中”，有些协议有可以调整的选项以减less确认的影响，但是它们都有需要考虑的权衡你的申请。
根据我的经验，瓶颈总是磁盘。 我从来没有使用iSCSI或SAN，因此遇到提高性能的唯一方法是使用带有专用RAID卡的RAID0。
优秀的tomshardware.com做了一篇关于如何在千兆以太网链路上实现100MBps的伟大文章 – 正如LG所说，这一切都归功于磁盘。
有一个阅读（ 这里 ），看看你的想法。