scpが非常に遅いのはなぜですか？

59

ファイルのバッチをコピーしようとしていますが、scp非常に遅いです。これは10ファイルの例です：

$ time scp cap_* user@host:~/dir
cap_20151023T113018_704979707.png    100%  413KB 413.2KB/s   00:00    
cap_20151023T113019_999990226.png    100%  413KB 412.6KB/s   00:00    
cap_20151023T113020_649251955.png    100%  417KB 416.8KB/s   00:00    
cap_20151023T113021_284028464.png    100%  417KB 416.8KB/s   00:00    
cap_20151023T113021_927950468.png    100%  413KB 413.0KB/s   00:00    
cap_20151023T113022_567641507.png    100%  413KB 413.1KB/s   00:00    
cap_20151023T113023_203534753.png    100%  414KB 413.5KB/s   00:00    
cap_20151023T113023_855350640.png    100%  412KB 411.7KB/s   00:00    
cap_20151023T113024_496387641.png    100%  412KB 412.3KB/s   00:00    
cap_20151023T113025_138012848.png    100%  414KB 413.8KB/s   00:00    
cap_20151023T113025_778042791.png    100%  413KB 413.4KB/s   00:00    

real    0m43.932s
user    0m0.074s
sys 0m0.030s

奇妙なことに、転送速度は約413KB / sで、ファイルサイズは約413KBであるため、実際には1秒あたり1ファイルを転送する必要がありますが、1ファイルあたり約4.3秒かかります。

このオーバーヘッドがどこから来るのか、それをより速くする方法はありますか？

scp time batch-jobs

— ローレン
ソース

3

どのような速度を期待しますか（つまり、同じ2台のマシン間でより高い転送速度を示す別のプロトコルがありますか）。はるかに大きなファイル（おそらく、すべての413KBファイルの連結）をscpするとどうなりますか？

— dhag

6

リモートシステムがクライアントIPアドレスを名前に解決しようとしているようで、セッションが進む前にタイムアウトを待つ必要があります。あなたはそれを修正することを調査することができます（例えば、IPアドレスを宛先の/ etc / hostsファイルに追加する）。

— ウルテル

4

-Cフラグを使用すると、転送中に圧縮が有効になります。あなたの問題は転送を開始するオーバーヘッドのようですが、圧縮は基本的に「無料」であり、ほとんどの場合に役立ちます。

— サム

@wurtel：私はあなたが見ているものが見えません、私が見るのは時間だけです。とにかく、単一のリバースDNSコールのみが必要です。

— ジェームズ・レインステートモニカポーク

セキュリティにSCPを使用していますか、それともリモートコピーのみに依存していますか？

— -Freiheit

17

@wurtelのコメントはおそらく正しいでしょう。各接続を確立するために多くのオーバーヘッドがあります。それを修正できれば、より高速な転送が得られます（もしできなければ、@ roaimaのrsync回避策を使用してください）。head -c 417K /dev/urandom > foo.1接続に時間がかかるホスト（HOST4）と非常に高速に応答するホスト（HOST1）に、同様のサイズのファイルを転送する（およびそのファイルのコピーを作成する）実験を行いました。

$ time ssh $HOST1 echo


real    0m0.146s
user    0m0.016s
sys     0m0.008s
$ time scp * $HOST1:
foo.1                                         100%  417KB 417.0KB/s   00:00    
foo.2                                         100%  417KB 417.0KB/s   00:00    
foo.3                                         100%  417KB 417.0KB/s   00:00    
foo.4                                         100%  417KB 417.0KB/s   00:00    
foo.5                                         100%  417KB 417.0KB/s   00:00    

real    0m0.337s
user    0m0.032s
sys     0m0.016s
$ time ssh $HOST4 echo


real    0m1.369s
user    0m0.020s
sys     0m0.016s
$ time scp * $HOST4:
foo.1                                         100%  417KB 417.0KB/s   00:00    
foo.2                                         100%  417KB 417.0KB/s   00:00    
foo.3                                         100%  417KB 417.0KB/s   00:00    
foo.4                                         100%  417KB 417.0KB/s   00:00    
foo.5                                         100%  417KB 417.0KB/s   00:00    

real    0m6.489s
user    0m0.052s
sys     0m0.020s
$

1

ありがとう、それは非常に興味深い。scpの出力は、ホストごとに完全に異なっていても同じ時間を示している場合は壊れています。おそらく、合計時間に接続時間を含める必要があります。

— ローラン

1

あなたの仮説は、ファイルごとに一度新しい接続を作成するということですか？

— ロジャードパック

59

あなたは使用することができますrsync（上のsshすべてのソースファイルを転送するための単一の接続を使用します）。

rsync -avP cap_* user@host:dir

あなたは持っていない場合はrsync（そしてなぜ！？ありません）を使用できtarてssh、一時ファイルを作成回避する、次のように：

tar czf - cap_* | ssh user@host tar xvzfC - dir

rsyncそれが中断した場合に再起動可能なので、他のすべてのものが等しい、好ましいことがあります。

— ロアイマ
ソース

6

単一のscp呼び出しでは、単一の接続を使用してすべてのファイルを転送しないと言っていますか？

— CVn

1

tarpipeの場合、f -tarはデフォルトでstdout / stdinに出力したり、stdout / stdinから読み込んだりするため、それぞれの側にある必要はありません。そうtar cz cap_* | ssh user@host tar xvzC dirするでしょう。

— 15年

1

@trembyとは限りません。tar異なるデフォルト値を使用してコンパイルできます（tar --show-defaultsGNU tarを使用しているかどうかを確認/etc/default/tarし、どちらの場合もTAPE環境変数を忘れないでください）

— -roaima

1

@MichaelKjörlingは、最初はscp各ファイルに新しい接続を作成すると想定していましたが、思い出して-と再確認した後tshark-私は間違っていることに気付きました。この時点で、OPがscpファイルごとにこれほど長い時間を要する理由がわかりません。

— ロアイマ

@roaima、興味深い、ありがとう。これまでのところ、stdin / stdoutがデフォルトではないことに気付いたことはありません。私のLinuxマシンのGNU tarは言及していますが、職場の私のMacのBSD tarは、manページでTAPE env varについて言及していません。

— 震災

15

時間のかかる転送のネゴシエーションです。一般に、bバイトのn個のファイルに対する操作はそれぞれ、n * bバイトの1つのファイルに対する単一の操作よりもはるかに長くかかります。これは、ディスクI / Oなどにも当てはまります。

よく見ると、この場合の転送速度はsize_of_the_file / secsであることがわかります。

ファイルをより効率的に転送するには、それらを一緒にバンドルしてからtar、tarball を転送します。

tar cvf myarchive.tar cap_20151023T*.png

または、アーカイブも圧縮する場合は、

tar cvzf myarchive.tar.gz myfile*

圧縮するかどうかは、ファイルの内容によって異なります。JPEGまたはPNGの場合、圧縮は効果がありません。

— dr01
ソース

PNGはdeflateを使用し、gzipすることも無意味です。

— Arthur2e5

ファイルをさらに圧縮できない場合、tarの圧縮は悪影響を及ぼさないので、置くだけの良い習慣だと思います-z

— Centimane

1

@Daveを圧縮できない場合、またはネットワークが高速の場合、速度が低下します。

— Davidmh

@Davidmhはこれはかなりの量になるでしょうか？すでに圧縮されているファイルを圧縮することは、圧縮できるものを実際に調べて、それが何もないことを見つけるので、かなり速いと思います。依存tar通常、圧縮のために2回目のパスを行うのか、それとも圧縮とアーカイブを同時に行うのか

— -Centimane

3

私の場合、@ Dave（最新の7000 rpm HD、ハイエンドCPU、非常に高速なネットワークのデータ、まったく自慢しない）、圧縮なしのtarは純粋にIOにバインドされて-zいますが、CPUにバインドされており、はるかに低速です。gzipは常に圧縮しようとするため、速度が低下します。結局のところ、バイト文字列を圧縮するかどうかは、圧縮を試みるまでわかりません。私の設定では、プレーンテキストファイルを転送する場合でも、圧縮なしのrsyncは、最も軽い圧縮に比べて2〜3倍速くなります。もちろん、YMMV。

— Davidmh

6

scpが、特に高帯域幅のネットワークで本来あるべき速度よりも遅いもう1つの理由は、静的に定義された内部フロー制御バッファがあり、ネットワークパフォーマンスのボトルネックになってしまうことです。

HPN-SSHは、これらのバッファーのサイズを増やすOpenSSHのパッチバージョンです。それは作る巨大 SCP転送速度に差が（サイト上のグラフを参照してください、私も個人的な経験から話します）。もちろん、利点を得るには、すべてのホストにHPN-SSHをインストールする必要がありますが、大きなファイルを定期的に転送する必要がある場合は価値があります。

— メンノ・スミッツ
ソース

5

並列gzipとnetcatを使用してデータをすばやく圧縮およびコピーする、ここで説明する手法を使用しました。

要約すると：

# SOURCE: 
> tar -cf - /u02/databases/mydb/data_file-1.dbf | pigz | nc -l 8888

# TARGET:
> nc <source host> 8888 | pigz -d | tar xf - -C /

これは、tarを使用してファイルを収集します。次に、pizzを使用して多くのCPUスレッドを取得し、ファイルを圧縮して送信します。ネットワーク伝送ではnetcatを使用しています。受信側では、netcatはリッスンしてから（並行して）解凍し、tarを解凍します。

— フライハイト
ソース

3

nc暗号化されていません。ssh -D多分いくつかの魔法を追加しますか？

— Arthur2e5

これは実際には非常に素晴らしいです

— ジャブランサイード

5

を介して大きなmp4ファイルのサイト間転送を行うこの問題が発生しましたscp。〜250KB / sを取得していました。宛先ファイアウォールでUDPフラッド保護（FP）を無効にした後、転送速度は6.5MB / sに増加しました。FPをオンに戻すと、レートは約250KB / sに戻りました。

送信者：cygwin、受信者：Fedora 20、ファイアウォールSophos UTM。

SSHは何のためにUDPを使用しますか？@ superuser.com - それは私が読んだものから直接ません。

ファイアウォールログを確認すると、プライベートサイト間内部VPNアドレスではなく、パブリックIPアドレスを介して送信元ポートと宛先ポート4500の両方でフラッド検出が発生していました。したがって、私の問題は、scpTCPデータが最終的に暗号化され、ESPおよびUDPパケットにカプセル化され、その結果FPの影響を受けるNATトラバーサル状況であると思われます。scp方程式から削除するために、VPNを介してWindowsファイルコピー操作を実行し、scpFPが有効な場合と有効でない場合と同様のパフォーマンスに気付きました。また、iperfTCPでテストを実行しましたが、FPがある場合は2Mビット/秒、ない場合は55Mビット/秒でした。

NAT-TはIPSecとどのように連携しますか？@ cisco.com

— bvj
ソース