我有一个问题困扰了我很久。我有多个环境和服务器。它们都连接到 1 Gbit 以太网交换机（例如 Cisco 3560）。
我的理解是，1 Gbit 链路应提供 125Mbyte/s - 当然这只是理论。但至少应该达到 ~100Mbyte/s。
这里的问题是，一次复制过程只能达到~20Mbyte/s。
我知道这些因素，但它们没有任何区别：
- 源和目标是否在同一交换机上
- 复制实用程序：SCP、Rsync、Windows copy、Windows robocopy
- SMB/CIFS、NFS、iSCSI
- 磁盘存储：NetApp FAS，本地连接的 15k SCSI
使用所有这些配置，我的吞吐量从未超过 ~25Mbyte/s。问题是，如果我启动多个并行复制流，比如 3 次 rsync，我几乎可以达到 90Mbyte/s。我还做了一些 IOMeter 测试，发现“chunksize”有很大的不同，但通常无法使用给定的工具进行调整（或者可以吗？）。
未启用巨型帧，但我不确定这是否会造成影响。所有 NIC 上都启用了 TOE。
您会想到哪些瓶颈？您有类似的经历吗？这些是预期的“自然”值吗？
提前致谢
答案1
如果这都是每个流的问题，那么您将面临“带宽延迟乘积”问题。基本上，一次“传输”的数据量是有限的（在 TCP 中，这是“窗口大小”），并且对于给定的往返延迟，您无法在给定的时间段内传输超过一定量的数据，因为发送方必须等待接收方确认已发送数据的收据，然后才能发送更多数据。粗略地说，您的 TCP 吞吐量将是窗口大小/往返延迟（以秒为单位）。
这不是只是TCP 问题（尽管我使用这个例子是因为如果你想进一步研究的话，它是文献最多的例子）。所有在发送更多数据之前等待确认的协议都会遇到同样的问题。理论上，你可以发送所有数据而不等待确认，但这通常被认为是一件坏事，因为你可以“淹没”接收者而不给他们任何阻止流水线的方法。
对于大多数协议，您可以调整窗口大小，以便可以同时拥有更多“飞行中”的数据，并且某些协议具有您可以调整的选项以减少确认的影响，但它们都有您需要为您的应用程序考虑的权衡。
答案2
根据我的经验，瓶颈始终是磁盘。我从未使用过 ISCSI 或 SAN，因此对我来说，提高性能的唯一方法是使用带有专用 RAID 卡的 RAID0。
答案3
一贯优秀的 tomshardware.com 发表了一篇关于如何通过千兆以太网链路实现 100MBps 的精彩文章 - 正如 lg 所说，这一切都取决于磁盘。
阅读（这里) 看看您怎么想。