☰

复制文件夹中数十万个 TB 的文件速度很慢

tag-icon • tag-icon samba zfs truenas file-transfer robocopy
复制文件夹中数十万个 TB 的文件速度很慢

我目前正在运行 FreeNAS，并在 Windows 计算机上使用 SMB 3 复制包含 80000 多个文件的文件夹，每个文件大约 35MB。以下是配置

自由网络存储

  • 2x40Gbps 连接绑定
  • 启用 SMB 3.1 的连接 SMB 共享
  • 1 个 Xeon 8 核处理器，配备 512GB RAM
  • 400TB 存储 RAID Z1 使用 4TB 驱动器来提高 IOP
  • 每个 RAID 组有 23 组驱动器，每组 5 个
  • 3x LSI 3008 SAS 3.0 12Gb/s 主机总线适配器
  • 可以在 thinkmate.com 上使用 SUPERSTORAGE SERVER 6048R-E1CR72L 作为基础进行类似配置，然后添加扩展底盘
  • 已启用巨型帧
  • 传输期间 CPU 使用率约为 50%
  • 传输期间 RAM 使用率为 60%

工作站

  • Windows 10 专业版
  • i7 3.6Ghz 和 16GB RAM
  • 512GB m.2 驱动器
  • PCI 3.0 16x 插槽中的 40Gbps 卡
  • 已启用巨型帧
  • TCP 卸载已禁用
  • 外部 RAID 0（3 或 4 个磁盘）驱动器通过 USB-C 连接
  • 传输期间 CPU 使用率为 20%
  • 传输期间 RAM 使用率为 15%

所以我有这些 RAID 0 驱动器，每个驱动器大约有 4TB 文件，每个文件为 35MB。每个文件夹大约有 80000 个文件。8 个工作站同时传输。

当我使用 robocopy 复制文件时，传输速度约为 1.8Gbps。然后随着时间的推移，复制越来越深入这些文件，速度下降到大约 600Mbps。无论我在 robocopy 上使用 /MT:1 还是 /MT:1，都会发生这种情况。EMCopy 的表现并没有好多少，而 freefilesync 大约 3 小时后就会死机。我希望它至少保持稳定在 1.8Gbps，而不是不断下降。在这些传输过程中，浏览工作站上的共享也变得无响应。还有其他人遇到过这种情况吗？

答案1

传输速率缓慢的根本原因可能是工作站 M2 驱动器需要进行大量随机读取。

高速 NVMe M2（我认为您最有可能使用）宣传的速度高达数 GB/sr/w。对于大文件的顺序读取来说确实如此，但对于您来说，您将获得随机读取。普通消费者/专业消费者 NVMe M2 SSD 的随机读取速率范围为 70MB/s 至 110MB/s，这在您的 600Mbps 速率范围内。SSD 的评论通常会包括随机读取速度结果，而我就是在这里得到这个范围的。

有一些 SSD，例如英特尔傲腾 SSD，可以提供大约 500MB/s 的随机读取速度。

此外，您还表示您通过 USB-C 连接驱动器。根据所使用的技术（USB3.0、3.1、3.2 或 Thunderbolt），此连接也可能会导致速度变慢。内部 NVMe M2 驱动器（或其他更快的基于 PCI-e 的驱动器）可能会解决此问题。

为了证明或推翻我的假设，您可以使用 Windows 10 任务管理器或性能监视器。任务管理器将为您提供驱动器繁忙程度的百分比。如果相关驱动器处于 100% 或高于 80% 的状态，则它们可能会限制速度。另一方面，如果它处于空闲状态，则不会限制速度。免责声明：我不知道 Windows 任务管理器的繁忙百分比有多可靠，尤其是对于外部驱动器。

如果事实证明源端的驱动器根本不忙，您可能需要检查目标端并查看驱动器在那里的运行情况（您可以使用工具 iostat 来实现）。

如果以上方法都无法帮到您，因为您已经排除了源端和目标端驱动器是导致问题的根本原因，那么我建议您从基本的故障排除步骤开始。例如，您可以传输一个大文件，看看这次传输是否受到同样的限制。您可以反转传输方向，并将一些小文件复制回工作站。如果反转就能让速度更快，那么也许有一个组件只在读取时有限制，而在写入时没有限制，反之亦然。

或者尝试通过直接连接设备来排除某些组件，中间不加任何额外的开关，或者从场景中移除任何可以进行测试的东西。

答案2

好的，看起来问题现在已经解决了。这是解决方案。

在里面/etc/samba/smb-shares.conf.local

这行已添加到我们正在使用的共享中

case sensitive = yes

现在我们的传输速度稳定在 200MBps。虽然不是理想的速度，但速度并没有随着时间的推移而降低。这解决了速度降低的问题。

答案3

无需进行广泛的分析两个都源和目标，很难给出明确的答案。话虽如此，我不认为源 NVMe 驱动器是瓶颈；毕竟，您正在读取相当大的文件，并且有大量的连续读取。

由于涉及的文件数量众多，我更倾向于认为 NTFS 和/或 SMB 协议本身效率低下。

我建议您尝试以下操作：

  • 在目标主机上，创建一个专用数据集，禁用同步、校验和和压缩（即：zfs set sync=disabled <dataset>等）。注意：你应该将此视为一个测试和/或临时解决方案，我这样做不是建议永久关闭这些设置运行；

  • 在源主机上，尝试使用 Linux Live CD/USB 启动并使用 NFS 协议（而不是 SMB）传输文件。您基本上应该执行以下操作：

    • 使用 Live CD 启动；
    • 安装 nfs 和 ntfs-3g 实用程序；
    • 挂载 NTFS 文件系统（即：在 中/mnt/localdir）；
    • 在目标上配置 NFS 导出；
    • 将其挂载到源主机上（即mount x.x.x.x:/dstdir /mnt/localdir：）；
    • 使用cp或rsync传输这些文件；
    • 在另一个终端上，尝试dstat -d -f -n运行两个都主机监控文件传输。

相关内容