朝6:30から初めて初めの1時間で2.4G.その後2時間かかってさらに1.8Gcopyしたよ。元fileを分割して複数のscpを実行すると加速できる。数で圧倒 という?初めからcoloradに本体があると知っていれば早かったかな。
scpが使えるなら ssh も動くよね? (スコア:1)
相手のマシン上へ ssh して「全部のファイルを tar で集めて、圧縮し、標準出力に出させる」
|(pipe)
「自分のマシン上で展開し、tar で展開」
の方が早いとよんだ。
fjの教祖様
Re:scpが使えるなら ssh も動くよね? (スコア:1)
# lzmaやxzだと、両側のCPUが早くないと圧縮に時間を取られてしまう。
Re:scpが使えるなら ssh も動くよね? (スコア:1)
Re:scpが使えるなら ssh も動くよね? (スコア:1)
tar |圧縮| ssh にはいくつかメリットがある。
1) ファイルの open/close のオーバーヘッドを scp ではなく tar が処理する。
ファイルの個数が多い場合、scp によって「ファイルの開閉」と「ファイルの転送」がシリアライズされないため、
微妙に早い。これは両端で発生するので、小さなファイルが大量にある場合馬鹿にできない。
2) tar でまとめてから圧縮すると圧縮効率が良い場合がある。
今時の圧縮ソフトは大抵
「LZで繰り返し検出圧縮」→「ハフマンとか算術圧縮とかのビットレベル圧縮」
という形式をとっているので、tar でパッキングするときに「同じようなたぐいのファイル」を隣接するように指定できると
繰り返しが発生/発見しやすくなり、圧縮効率がかなり上がる。
ちなみに Winzip 使うな、tarball 使え、も同じ理由である(Winzip はファイルごとに圧縮するので、ファイル間
の類似性に起因する圧縮率の向上が発生しない)
3) 圧縮方式に「より新しい」ものを選べる。
乱暴な話 xz 対応の scp はないが tar はあるし、tar が xz に対応してなくても pipe で xz 通せばいいし…
ちなみに xz のデフォルトは xz -6 なので、早くしたければ xz -4 ぐらいを選ぶと良い。
(CPU性能に自信が無ければ -3 とか -2 とか…)
xz の man page にはいろいろこの辺のパラメータがどういう意味を持つのか書いてあって楽しい。
もちろん、両側のCPUが遅い/通信回線が太いなら bzip2 辺りで…など、マニュアルチューニングがしやすい。
同じ bzip2 だって -1 から -9 までである程度速度に差が出るので、そのへんのバランスもいじりやすい。
まぁ、大抵の場合のメリットは 2 ですが、場合によっては 1 が大きく寄与することもあります。
fjの教祖様
Re:scpが使えるなら ssh も動くよね? (スコア:1)
>1)
(中略)
> 微妙に早い。これは両端で発生するので、小さなファイルが大量にある場合馬鹿にできない。
小さなファイルが大量の場合は、受け側で、ファイル1つ毎にディレクトリエントリとかを生成するとこが律速になるかも。
# GNU tarって、tar xで展開するファイル毎にfsync()してたよなぁ…って、今ソース見たら、(tar cで固めた)アーカイブのみでした。
Re:scpが使えるなら ssh も動くよね? (スコア:1)
その間もデータ送信を止めないのが tar|圧縮|ssh の良い所です。受け側でバッファリングしてる。
scp だとファイルを作って「受信準備オッケー」という状態を送受信双方で確認するまで中身の転送を始めないんだよね…もちろん、cp の「secure/remote 版」という観点からすればそっちで正しいんだけど…
fjの教祖様
圧縮は別の話だろ。 (スコア:1)
日記ではTCPの輻輳制御の話をしてるんじゃねーかなー。
Re:圧縮は別の話だろ。 (スコア:1)
輻輳制御が真の問題なら、scpを2つ以上動かしても速度は(ほとんど)上がらない。
fjの教祖様
Re:圧縮は別の話だろ。 (スコア:1)
どうやら知らんで言ってるようだな。