我们有一个 130GB 大小的文件夹，其中包含数百万个微小 (5-20k) 图像文件，我们需要将其从旧服务器 (EC2) 移动到新服务器 (Hetzner, Germany)。
我们的 SQL 文件 SCP 很快就完成了——至少 20-30mb/s——而且前约 5gb 左右的图像传输也很快。
然后我们回家了一天，今天早上回来，我们的图像传输速度减慢到只有约 5kb/s。RSync 在达到工作负载的中间时似乎变慢了。我已经研究过替代方案，比如gigasync（这似乎不起作用），但每个人似乎都同意 rsync 是最好的选择。
我们有这么多文件，ls -al完成需要一个多小时，而且我所有尝试使用 python 将我们的传输批量传输到更小的部分都已经耗尽了所有可用的 RAM，但没有成功完成。
如何使用现成的工具和一些轻量级脚本以合理的速度传输所有这些文件？
性能问题很可能不在于其rsync本身，而在于单个目录中有这么多文件。很少有文件系统能在像这样的单个大文件夹中表现良好。您可能会考虑重构该存储以使用子目录的层次结构。
但是，由于听起来您实际上是在进行一次性传输，因此您可以尝试类似 a 的方法tar cf - -C <directory> . | ssh <newhost> tar xf - -C <newdirectory>- 这可能会消除一些额外的每个文件通信rsync和额外的往返延迟，但我不'认为这不会有显着改善......
另外，请注意，如果ls -al需要一个小时，那么当您接近传输结束时，创建每个新文件可能会花费大量时间（几秒钟甚至几分钟），因为它首先必须检查目录中的每个条目，以查看它实际上是在创建新文件还是覆盖旧文件。
我不知道它是否会明显更快，但也许是
cd /folder/with/data; tar cvz | ssh target 'cd /target/folder; tar xvz'
会成功的。
如果可以的话，也许可以重组你的文件排列。在类似的情况下，我将文件按项目或仅按 1000 个分组在一起，这样一个文件夹就不会同时包含太多条目。
但我可以想象，rsync保持传输文件列表的必要性（否则我也非常喜欢）是造成速度缓慢的原因。如果rsync进程占用太多 RAM 以至于必须进行交换，那么一切都将丢失。
因此，另一种选择可能是rsync逐个文件夹。