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