此屏幕截图是我在同一物理机器上将一个大文件 (.VHD) 从一个逻辑卷 (由 RAID0 中的 2 个主轴组成) 传输到另一个逻辑卷 (由 RAID0 中的 2 个主轴组成)。 (这不是生产，所以不必担心硬件配置的完整性。) 我通过同一 LAN 上的第三台机器上的 explorer.exe 启动了传输，因此某些 TCP 协议可能与此犯罪有关；我不知道。
当文件传输开始时，它的峰值约为 220MB/秒，这是我期望在这台机器上进行卷到卷的传输的速度，然后在大约 50% 的传输过程中，速度下降到大约 50-75MB/秒，并以大约这个速率结束。
你知道为什么从一个卷到另一个卷的文件传输速率在传输过程中始终减半吗？我对相同的传输进行了几次测试，每次都得到了完全相同的行为。
编辑：我使用 robocopy 而不是 Explorer 再次进行了测试。我使用的是不同的文件，但我仍然从第三个工作站启动复制：
在使用 robocopy 复制文件的过程中，我没有观察到速度急剧下降的情况，但是，如果你查看最后的传输速度，它仍然远远高于千兆以太网的理论极限。
编辑 #2：这是通过 Explorer 查看的相同传输。此文件没有减速。唯一的区别是此 VHD 的大小约为第一个 VHD 的一半：
两种不同工具提供的一致证据表明文件复制速度比 GigE 能够提供的速度要快，因此我仍然不相信传输是通过网络进行的。但我仍然不知道为什么一开始较大的文件会在传输过程中变慢。也许这个实验中有很多变量/因素。
答案1
传输正在通过网络进行。假设这些桌面都通过千兆以太网连接，60-70MB/s 是文件传输的相当典型的速度。您提到的“第三个桌面”不知道也不关心这两个共享是否在同一个物理盒子上。它只知道它正在从共享 A（源 RAID0）复制到共享 B（目标 RAID0），并且这两个都是网络目标。
修复很简单：使用远程桌面登录到具有 RAID0 阵列的框并以此方式启动文件复制。
答案2
您的场景中有三个主要瓶颈：
- 源可能无法以更快的速率提供数据，通常是由于碎片化造成的
- 网络可能拥塞（不太可能，因为可以重现）
- 目标可能无法以更快的速度写入数据 - 图表可能表明一些初始的后写缓存，并且一旦缓存被填满，速率就会下降到实际的存储速度（这是我最好的猜测）
您应该分别测试每个瓶颈：
- 将源文件复制到
nul本地 - 运行合成网络吞吐量测试（例如 iperf3）
- 将（合成）测试文件写入目标磁盘本地（
dd风格或存储基准）
其他潜在瓶颈是上述项目的相互依赖性，例如主机 CPU 无法同时处理存储和网络负载。如有必要，可以通过结合上述几点来测试这些。