傳輸數以百萬計的圖像-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需要一個小時，那麼當你接近轉移結束時，創建每個新的文件可能需要大量時間（秒或甚至幾分鐘），因爲它首先必須檢查目錄中的每個條目，以查看它實際上是創建新文件還是覆蓋舊文件。