4

サイズが 130GB のフォルダーがあり、何百万もの小さな (5 ～ 20k) 画像ファイルがあり、それを古いサーバー (EC2) から新しいサーバー (Hetzner、ドイツ) に移動する必要があります。

私たちの SQL ファイル SCP は非常に速く (少なくとも 20 ～ 30 mb/s)、最初の ~5 GB 程度のイメージも非常に速く転送されました。

その後、その日は家に帰り、今朝戻ってくると、画像の転送速度がわずか 5kb/s まで低下しました。RSync は、ワークロードの途中で遅くなるようです。私はgigasync (これはうまくいかないようです) などの代替手段を調べましたが、誰もが rsync が最良の選択肢であることに同意しているようです。

非常に多くのファイルがls -alあり、1 時間以上かかります。Python を使用して転送を小さな部分にまとめようとする試みはすべて、利用可能なすべての RAM を消費してしまい、正常に完了しませんでした。

すぐに利用できるツールと簡単なスクリプトを使用して、これらすべてのファイルを適切な速度で転送するにはどうすればよいでしょうか?

4

2 に答える 2

4

パフォーマンスの問題はrsyncそれ自体にあるのではなく、1 つのディレクトリに多くのファイルがある結果である可能性があります。そのような単一の巨大なフォルダで適切に機能するファイル システムはほとんどありません。そのストレージをリファクタリングして、サブディレクトリの階層を使用することを検討してください。

ただし、基本的に1回限りの転送を行っているように聞こえるので、次のような方法で何かを試すことができますtar cf - -C <directory> . | ssh <newhost> tar xf - -C <newdirectory>。rsyncそれが大幅な改善をもたらすとは思わない...

また、ls -al転送に 1 時間かかる場合は、転送の終わりに近づくまでに、最初にチェックする必要があるため、新しいファイルを作成するのにかなりの時間 (数秒または数分) かかる可能性があることに注意してください。ディレクトリ内のすべてのエントリを調べて、実際に新しいファイルを作成しているのか、古いファイルを上書きしているのかを確認します。

于 2012-06-14T17:58:01.957 に答える
4

大幅に速くなるかどうかはわかりませんが、おそらく

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

トリックを行います。

可能であれば、ファイルの配置を再構築してください。同様の状況で、ファイルをプロジェクト単位または 1000 単位でグループ化して、1 つのフォルダーに一度に多くのエントリが含まれないようにします。

しかし、転送されたファイルのリストを保持する必要性rsync(それ以外の点でも非常に気に入っています) が、速度低下の原因であると想像できます。プロセスがスワップしなければならrsyncないほど多くの RAM を占有すると、すべてが失われます。

したがって、別のオプションは、rsyncフォルダーごとに行うことができます。

于 2012-06-14T17:58:42.833 に答える