传输数以百万计的图像-RSync不够好

Question

我们有一个文件夹，130GB大小，数百万个微小（5-20​​k）图像文件，我们需要将它从旧服务器（EC2）移动到我们的新服务器（德国Hetzner）。

我们的SQL文件非常快速 - 至少20-30mb/s - 并且第一个〜5GB左右的图像传输速度也非常快。

然后，我们回家了一天，今天早上回来，我们的图像已经放缓到只有~5kb/s的转移。 RSync似乎放慢了工作负载的中间。我已经研究过替代品，例如gigasync（似乎不起作用），但每个人似乎都认为rsync是最好的选择。

我们有这么多的文件，做ls -al需要一个多小时，我所有的尝试使用python将我们的传输分成更小的部分已经吃掉所有可用的RAM，但没有成功完成。

如何使用随时可用的工具和一些轻型脚本以合理的速度传输所有这些文件？

Answer 1

我不知道这是否会显著快，但也许

cd /folder/with/data; tar cvz | ssh target 'cd /target/folder; tar xvz' 

会做的伎俩。

如果可以，也许重构你的文件安排。在类似的情况下，我将这些文件按项目方式进行分组，或者只将1000个分组放在一起，以便一个文件夹一次不会有太多条目。

但我可以想象，rsync（我也很喜欢）的必要性来保存传输文件的列表是造成缓慢的原因。如果rsync进程占用大量内存以致必须进行交换，则全部丢失。

因此，另一种选择可能是按文件夹的rsync文件夹。

Answer 2

性能问题很可能不是rsync本身，而是因为在单个目录中有很多文件。很少有文件系统可以很好地处理像这样的单个巨大文件夹。您可能会考虑重构该存储以使用子目录的层次结构。

因为听起来你基本上只是一次性转移，所以你可以尝试一些沿着tar cf - -C <directory> . | ssh <newhost> tar xf - -C <newdirectory>的行 - 这可能会消除一些额外的每文件通信rsync的做法，旅行延迟，但我认为这不会有显着的改善...

另外，请注意，如果ls -al需要一个小时，那么当你接近转移结束时，创建每个新的文件可能需要大量时间（秒或甚至几分钟），因为它首先必须检查目录中的每个条目，以查看它实际上是创建新文件还是覆盖旧文件。