大きなファイル(〜20 GB)をコピーするためのcpの高速な代替手段はありますか?


40

私は大学院生であり、私が働いているグループはLinuxクラスターを維持しています。クラスターの各ノードには独自のローカルディスクがありますが、これらのローカルディスクは比較的小さく、自動バックアップは装備されていません。そのため、グループは多くのTBのストレージスペースを持つファイルサーバーを所有しています。私は比較的Linuxに慣れていないので、速度、ネットワーク機能などの点でファイルサーバーの仕様がわからない。ローカルディスクがI / Oの点でファイルサーバーよりもかなり高速であることは経験から知っている。約十数人がファイルサーバーを使用しています。

cp〜20 GBのファイルをファイルサーバーからローカルディスクの1つにコピーするために使用するには、平均で約11.5分かかります(によればtime)。cp(1)timeそのようなコピーのシステム時間は約45秒であるため、この操作はあまり効率的ではないことを知っています。(2)topコピー中に調べると、%CPUは非常に低いため(検査により、平均で約0〜10%)。

cpローカルディスク上の1つのフォルダーから同じローカルディスク上の別のフォルダーに同じ〜20 GBのファイルをコピーするために使用すると、時間がかかりません-リアルタイムで約9分(システム時間では〜51秒time)。そのため、ファイルサーバーは予想どおりローカルディスクよりも多少遅くなりますが、おそらくそれほど遅くありません。ローカルから同じローカルへのコピーが9分より速くないことに驚いています。

ファイルサーバーからローカルディスクの1つに、最大200個の大きなファイル(それぞれ20 GB以下)をコピーする必要があります。だから、私の質問は次のとおりですcp。Linuxで大きなファイルをコピーするためのより高速な代替手段はありますか? (または、cpコピーを高速化するために使用できるフラグがありますか?)このコピー時間を何らかの形で削ることができたとしても、それは非常に役立ちます。

新しい高速のハードウェアディスクを購入することは確かですが、そのようなリソースにアクセスすることはできません。私はシステム管理者でもありません-私は(初心者)ユーザーでしかありません-そのため、ディスクの負荷に関するより詳細な情報にアクセスすることはできません。毎日約12人がファイルサーバーを使用していますが、この特定のノード/ローカルディスクを使用しているのは私だけです。


29
これは約29MB / sになりますが、私に聞けばかなり速いです。これを高速化するコマンドはないと思います。「ボトルネック」は、a)ネットワークまたはb)ファイルサーバーである可能性が高いです。
ティンク

5
tinkは100%正しいです。これを改善できるものを見たことはありません。私が過去に行った唯一のことは、データを送信する前に圧縮することですが、それは、圧縮ステップと解凍ステップに時間を追加することを意味しますが、データが適切な候補である場合、それは価値がある場合があります圧縮!
slm

3
あなたも試すことができますddし、rsyncより高速な環境内のどの1作品を比較する
ラザ

@サルトンありがとう。まだ試していませんがdd、試しましたrsync。によると、リアルタイムは約11.5分、システム時間は約1.5分でしたtime
アンドリュー

2
複数のディスクをマウントすることで、ローカルディスクからローカルディスクへのコピーをより効率的にできることを誰も指摘していないことに驚いています。から/dev/sda1への/dev/sdb1コピーは、ある場所/dev/sda1から別の場所/dev/sda1または別のパーティションへのコピーよりも高速/dev/sdaですSSDは明らかに異なります)。
トリプリー

回答:


53

コピー中、%CPU 低くなければなりません。CPUは、ディスクコントローラーに「セクターXからYのデータをZのメモリーバッファーに取り込む」よう指示します。その後、他の何かを実行します(他に何もない場合はスリープします)。ハードウェアは、データがメモリ内にあるときに割り込みをトリガーします。次に、CPUはそれを数回コピーする必要があり、ネットワークカードに「メモリロケーションA、B、およびCでパケットを送信する」ことを伝えます。その後、別のことを行うことに戻ります。

〜240mbpsをプッシュしています。ギガビットLANでは、少なくとも800mbpsを実行できる必要がありますが、次のことが必要です。

  1. これは、ファイルサーバーを使用するすべての人(およびスイッチ間の接続など)で共有されます。
  2. これは、ファイルサーバーが書き込みを処理できる速度によって制限されます。そのディスクI / O帯域幅は、それを使用するすべてのユーザーによって共有されることに注意してください。
  3. ファイルサーバーへのアクセス方法(NFS、CIFS(Samba)、AFSなど)を指定しませんでした。ネットワークマウントの調整が必要になる場合がありますが、最近の半分では、デフォルト値は通常かなり健全です。

ボトルネックを追跡するにはiostat -kx 10、便利なコマンドになるでしょう。ローカルハードディスクの使用率が表示されます。ファイルサーバーで実行できる場合は、ファイルサーバーの負荷がわかります。

一般的な解決策は、そのボトルネックをスピードアップすることです。もちろん、これには予算がありません。しかし、より高速なアプローチを見つけることができる特別なケースがいくつかあります。

  • ファイルが圧縮可能で、CPUが高速の場合、オンザフライで最小限の圧縮を実行する方が高速になる場合があります。何かのようなlzopまたは多分gzip --fastest
  • あちこちで数ビットだけを変更してからファイルを送り返す場合、デルタのみを送信する方がはるかに高速です。残念ながら、rsyncデルタを見つけるには両側でファイルを読み取る必要があるため、ここではあまり役に立ちません。代わりに、ファイルの変更時にデルタを追跡するものが必要です...ここでのアプローチのほとんどはアプリ固有のものです。ただし、たとえばdevice-mapper(新しいdm-eraターゲットを参照)またはbtrfsで何かをリグできる可能性があります。
  • 同じデータを複数のマシンにコピーする場合、udpcastなどを使用して、すべてのマシンに一度に送信できます。

そして、あなたはあなたがシステム管理者ではないことに気付くので、それはシステム管理者を持っていることを意味していると推測しています。または、少なくともファイルサーバーとネットワークの責任者。おそらく彼/彼女/彼らに尋ねるべきです。彼らはあなたのセットアップの詳細にもっと精通しているべきです。あなたのシステム管理者は、少なくともあなたが合理的に期待できる転送速度を教えてくれるはずです。


iostat -kx 10の+1 :
n611x007

16

これはおそらく、より高速な代替手段になる可能性があり、2日間ネットワークを詰まらせることはありません。1つまたは2つの大きなUSB(USB 3がある場合)またはFireWireディスクを取り出し、サーバーに接続してファイルをコピーしますディスク。ディスクをローカルマシンに持ち込みます。ファイルをマシンにコピーします。


23
Sneakernet(en.wikipedia.org/wiki/Sneakernet)は非常に高速である可能性があります。高速道路を走るテープでいっぱいのステーションワゴンの帯域幅を過小評価しないでください。
SplinterReality

10

あなたの効率の定義は後方です。より効率的な実装は、CPU時間を無駄にしません。ローカルコピーでは、平均で約74 MB / sのスループット(読み取り+書き込み)であり、これは単一のハードディスクが取得するのとほぼ同じ程度です。


1
おっとっと。「効率的」と言ったとき、「速い」という意味でした。
アンドリュー

10

直接SSH(またはSFTP)アクセス(システム管理者に問い合わせる)がある場合はscp、圧縮(-C)で使用できます。

scp -C you@server:/path/to/yourfile .

もちろん、これはファイルが圧縮可能な場合にのみ有用であり、暗号化(SSH経由であるため)を使用し、圧縮するため、より多くのCPU時間を使用します。


この場合、暗号化を無効にすると便利です。コピーを高速化しようとしていることを忘れないでください。
lgeorget

3
@lgeorgetハードドライブの速度がどれほど遅いかを考えると、暗号化のオーバーヘッドはそれほど大きくないと思います。何かを追加することを検討しました-c noneが、それは標準的ではないようです。
モニカ

1
〜20Gのファイルを扱っているため、不要な場合に暗号化を使用するのかなり非効率的です。
lgeorget

1
@lgeorget暗号化は、彼が得ているスループットよりもはるかに高速に実行できるため、速度が低下することはありません。ただし、ここでSSHを使用する必要はありません。圧縮のみが必要な場合、他のツールがありますか?
トーマス

@Thomas SSHの利点は、リモートサーバーにアクセスすることになっている場合、ほぼ確実にSSHを実行していることです。別のオプションは、それが、その後、サーバーにコピーし、ローカルにファイルを圧縮するだろうsshに、それを解凍...
復活モニカ

8

cp実装は、最も可能性の高いボトルネックではありません。iotopサーバーとクラスターノードの両方でIO使用量を観察してみてください。これにより、パフォーマンスを改善できる場所がわかります。

別のヒントは、同じホストから同じデータをコピーしないようにすることです。たとえば、ファイルサーバーからネットワーク経由ですべてのクラスターノードに配布する同一の20Gファイルがある場合、1サーバーからすべてのクライアントにではなく、ピアツーピア形式でファイルをコピーする方がはるかに高速に動作します。実装は少し複雑ですが、直接接続ハブのようなコマンドラインp2pを使用することもできます。

その20Gファイル内で、一部が共通であり、一部がクラスターノード固有である場合、それを共通部分と特定部分に分割してから、共通部分をp2p方式で配布することを検討してください。


1
LANを使用している場合は、ピアツーピアではなくマルチキャストを実行できます。これは高速で、ネットワークへの負荷が少ないはずです。
デロバート

8

これらのファイルの性質/内容によって、多少の違いが生じる可能性があります。あるコンピューターから別のコンピューターに、それぞれ20 GBまでの200個のファイルをコピーする必要があることを理解しました。

これらのファイルが圧縮可能であるか、類似または同一の断片である場合、2つのアプローチがあります。

  • コピーする前にzipするか、zipが有効になっているコンピューター間にトンネルを作成します。したがって、ネットワークがボトルネックの場合、少し速くなります

  • ファイルが非常に似ている場合、またはファイル間で共通のコンテンツを共有している場合は、rsyncを使用してみてください。ファイル間で一般的なものを見つけるのに少し時間を費やしますが、文字通りコピーする必要はありません。一般的なものに基づいて再構築するからです。

編集する

それらのファイルを何度もコピーする必要がありますか?(コピーのように->それらのファイルを使用する->コンピューターAのファイルの一部を変更する->コンピューターBにファイルを再度コピーする)

そうである場合、バージョン間で等しいものを検出し、変更されていないものをコピーしないので、rsyncが役立ちます。

3番目の方法:上記が正しい場合(ファイルの変更後、すべてのファイルを2番目のコンピューターに再度コピーする場合)binary diff、最初のコンピューターで変更されたものを2番目のコンピューターで変更しようとすることができます。


6

暗号化は転送されるデータの量を増やす可能性があるため、ここでは次のことを確認します。

2つのシステム間でコピーする場合、ボトルネックはもちろんサーバー間の接続です。

ローカルにコピーしている場合は、プロセスがどのように進行するかを確認してください。シングルスレッドであるため、標準のLinuxユーティリティは次を使用します。

- for all blocks in a file
      read a block
      write a block

この操作には並行性はありません。

速度を上げるには、次のようなものを使用できます。

  buffer -i infile -o outfile -m size-of-shared-memory-default-1MByte

詳細については、buffer(1)のマニュアルページを参照してください。

bufferコマンドは、コピープロセスを同時に実行する2つのプロセスを設定します。1つは読み取り用、もう1つは書き込み用で、共有メモリバッファを使用して2つのプロセス間でデータを通信します。共有メモリバッファは、書き込まれていないデータの上書きや、すでに書き込まれたデータの書き込みを防ぐ古典的な循環バッファです。このプログラムを使用して、ディスクからテープへの転送でコピー時間の約10〜20%をカットしました。


実際には、「ブロックの読み取り/ブロックの書き込み」には並行性があります。これは、「ブロックの書き込み」が実際にカーネルのバッファーに置くだけであり、カーネルが実際のブロック書き込みをバックグラウンドで処理するためです(少なくとも、実行が開始されるまでRAMの)。または、何らかの理由でO_DSYNC / O_SYNCを使用している場合。
デロバート

3

クラスター全体を同時に更新する必要がある場合は、P2P伝播アルゴリズムを試してみませんか?

https://github.com/lg/murderはtwitterが使用するものです

ありますBTSYNCあなたが同様に試すことができること。


1

同じファイルのセットを頻繁にローカルコンピューターからサーバーにコピーする場合は、多少の変更を加えます。rsyncまたはDVCS(例:hgまたはgit)を使用して、転送を高速化できます。

gitまたはhgは、デルタを追跡および検出し、それらのデルタのみを転送できます。gitを使用する場合、両方の側にリポジトリの完全な履歴があるため、デルタを見つけることは非常に安価です。

rsyncは、ローリングチェックサムアルゴリズムの形式を使用して、相手側の事前知識なしにデルタを検出します。rsyncがデルタを計算するにはより多くの作業が必要ですが、ファイル履歴全体を保存する必要はありません。


1

すべてのファイルを1つのアーカイブにパッケージ化することをお勧めします(圧縮しないでください)。私の経験では、1つのアーカイブをコピーする方が、個々のファイルを大量にコピーするよりも高速です


3
良い一般的な観察ですが、質問で「〜200の大きなファイル-それぞれ〜20 GB」と書かれているように、これがこの問題に対する実際の答えとは考えられません。
マナトワーク

@manatwork ah ..はっきりと読みませんでした。私は彼が合計20ギガバイトの200個のファイルを持っていると思った
Munim

0

bbcpを試してください。私たちの環境でテストした結果、cpには何らかのガバナーが組み込まれていることがわかりました。ガバナーを外すと、サーバーをレッドライン化して停止する可能性があるため、注意してください。私たちの場合、コピーを実行するためにサーバーをオフラインにしていたので、高速であったほうが良いです。これにより、転送時間が数時間改善されました。


0

コピーする前に、ターゲットファイルが存在しないことを確認してください。

同じホスト上でコピーするだけでも、どれだけの時間が費やされるか驚くかもしれません(ネットワークが関与していません)。

ここで別のcp質問への私の答えを参照しください。要するに、既存のファイルの上書きは、最初にファイルを切り捨てたり、リンクを解除してからコピーするよりもはるかに遅いです。後者は、1.2GBファイルで8倍高速です。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.