locked
ROBOCOPYにマルチスレッドオプションを付けても処理時間が変わらない RRS feed

  • 質問

  • ROBOCOPYに /MT オプションを付けて実行しているのですが、

    /MT無しの場合と、/MT有りの場合、またスレッド数を変えても処理時間が変わりません。

    オプションは下記のように設定しています。

    robocopy "\\ファイルサーバのIPアドレス\hoge" "C:\hoge" /mir /copy:DATS /mt:8 /r:0 /w:0 /log+:C:\hoge.log /nfl /ndl /tee

    ①コピー元のOS: WinSv 2008 R2

    ②コピー先のOS: Win7

    ROBOCOPY実行マシン: 上記②

    コピー元とコピー先のファイル、フォルダは同じ内容で、全てスキップされる状態。

    コピー元の合計サイズ、ファイル数、フォルダ数は下記です。

    合計サイズ: 14GB

    ファイル数: 12,000

    フォルダ数: 1,300

    スレッド数を色々変えてみましたが、処理時間が全て同じで短縮されません。(30秒前後)

    コピー元とコピー先の比較処理はマルチスレッドにならないのでしょうか?

    ご存知の方お教えください。





    • 編集済み LLBonny 2015年6月12日 7:29
    2015年6月12日 7:19

すべての返信

  • LLBonny さま よろしく。

    大変興味のある内容でしたので、少し、検索して見たのですが、明確なものは見付かりませんでした。

    以下は、個人的な推測です。

    マルチスレッド化はオーバーヘッドが加わるので、全ての処理を平行して実施しているとは思えません。
    恐らく、ファイルの精査の部分が大元のスレッドで、ここから、データ転送部分がマルチスレッド化されているのではないでしょうか。
    特に、オプションを与えなくても、双方が対応する環境(今回のケースも)ならば、既定で 8 のスレッドとありますし。
    従って、実データの転送を伴わない、属性変更ではマルチの恩恵を受けていない気がします。
     (仮に、この条件でマルチ化しても、実効速度が低下する恐れもあるのでは無いでしょうか。)


    実際の所、私も、この点は、有識者の見解を知りたいです。


    尚、コマンドラインのヘルプには以下の様に記述されていますが、 ご質問でも、そうなっていますね。
         パフォーマンスの向上のため、/LOG オプションを使用して出力をリダイレクトします。
    2015年6月12日 8:16
  • oooohです。

    robocopyの説明はちゃんと読みましたか?

    規定値8とあるように、MTオプションを8で明記するのと、

    オプションを指定しないのでは動作的に同じかと思いますが。

    また、Win7端末のCPUがそもそも8スレッド以上処理できるもの(Core i7以上)ですか?

    2015年6月12日 9:03
  • ShiroYuki_Mot 様

    返信頂きありがとうございます。

    > 従って、実データの転送を伴わない、属性変更ではマルチの恩恵を受けていない気がします。

    ということは、属性のコピー(/COPY:DATS)もマルチスレッドにならないという推測でしょうか?

    次に。。。 気になったので、データ転送がマルチスレッドになるのか、空のコピー先を用意して試してみました。
    コピー元とオプションは同じです。
    結果は下記でした。

    /MT無し   28分
    /MT:2    23分
    /MT:8    23分
    /MT:128  23分

    ROBOCOPYを実行しているPCのスペックも関係すると思いますが、
    2と8でここまで変化が無いものなのでしょうか??


    2015年6月12日 9:23
  • ooooh 様

    返信頂きありがとうございます。

    8は明示的に付けただけです。

    CPUは Core i3 ですが、調べてはいたものの情報が見つからず、関係ないものと思っていました。

    尚、スレッド数4でも試してみましたが、時間は変わらずです。
    2015年6月12日 9:59
  • LLBonny さま 拝見しました。

    SysInternals の Process Explorer (procexp.exe) で CMD.exe から起動される Robocopy の挙動を見て見ました。
    コマンドは
    C:\Windows\system32>robocopy L:\Test \\SERVER\Master\Test /S /DCOPY:T
    Client は i7 相当で 4コア8スレッド Server は i3 で2コア4スレッドです。
    ファイルは 約 290 ファイル、3.6GB で、Server には存在しない Folder です。
    つまり、既定で スレッドは 8 の筈ですが、実際に、ファイル転送が始まっても当初は1スレッド、後に4スレッドでした。
    このケースでは、物理コア数の4しかスレッドが作成されず、最高スレッド数でした。
    いや、Server 側の4スレッドの制限なのかも知れません。

    あまり詳しくないので、詳細は分らないのですが、Process Explorer でタイムリーに追跡出来ます。
    https://technet.microsoft.com/ja-jp/sysinternals/bb896653.aspx?f=255&MSPPError=-2147217396
    ご参考まで。

    • 編集済み ShiroYuki_Mot 2015年6月12日 12:28 Server 側のスレッドの制限の可能性を追記
    2015年6月12日 12:10
  • マルチスレッドで速くなる原理が不明。所詮ioバウンドなのだから、マルチスレッドにしたところで。

    メインフレームで磁気テープのioを速くするため、チャネルプログラムとバッファを2セット用意して、交互にチェインスケジュールした。1セットと2セットでは雲泥の違いだけれど、3セット以上は意味がない。

    cpuとioが並行して動ける部分は短縮できるだろうけど、それ以上は。

    入力側と出力側の装置が異なれば、その2多重は効きそう。

    2015年6月12日 14:06
  • 私も同意見で、マルチスレッドにすれば速くなる論理はないと思います。
    I/O、つまり、ネットワークの転送(やディスク読み書き)がボトルネックである可能性が高く、CPU をいくつ使おうが、改善しません。
    並列に実行すると、逆に完了が遅くなる可能性すらある話だと思います。

    全部転送すると仮定した場合、14GB = 14,336MB が 23 分、分あたり 623MB、秒あたり 10.38MB、ビットレートに直すと 83.11Mbps ぐらいですかね?
    100Mbps のネットワークならそんなものではないかと思いますが、ギガビット(1,000Mbps)であるとか、ディスクの転送速度も十分速いとか、疑うに足る根拠をお持ちなのであれば、その根拠も明示してください。

    (ファイルの比較処理において、CPU パワーはそんなにいらず、I/O がコストの大半を占めると考えます。「マルチスレッドによる並列化」はあくまで CPU による演算量をコアごとに振り分けることで時間を短縮するだけであり、I/O を効率よくできる処理できる仕組みではありません)
    2015年6月12日 14:24
  • ウィンドウズスクリプトプログラマ さま 拝見しました。

    確かに、マルチスレッド化で速くなるかと言われると疑問があります。
    マルチスレッドはオーバーヘッドが伴い、余計な処理が含まれますから。
    一般論ではトータルの処理時間は多くなる事が多いとも聞きます。

    但し、これは、その処理を単独に見た場合で、
    スレッドが複数になれば、OS 配下でタイムスライスされた個々のスレッドに処理が回って来る期間が短縮出来ます。
    3セット以上は意味がない ならば、Windows7 で robocopy をマルチスレッド化する際にそうしている筈です。

    仰る様に、IO の実際のファイル操作は OS 内部のファイルシステムなので、 ... 複雑ですね。
    2015年6月12日 14:45
  • Azulean さま 拝見しました。

    確かに、マルチスレッド化で速くなるかと言われると私も疑問があります。

    IO がボトルネックになる点は理解出来るのですが、
    Windows7 で robocopy をマルチスレッド化した訳で、 何かメリットを見出したからでは無いのでしょうか?。
    その何か? が分りません!。
    2015年6月12日 15:06
  • IO がボトルネックになる点は理解出来るのですが、
    Windows7 で robocopy をマルチスレッド化した訳で、 何かメリットを見出したからでは無いのでしょうか?。
    その何か? が分りません!。
    ストレージの速度、伝送経路の速度、CPU など、様々な組み合わせがある中、有効に働く場合もあれば、効果がない場合、悪化する場合と様々なパターンがあることが予想されるわけですから、robocopy でマルチスレッド対応した理由を求めることは、問題解決に結びつかないと私は思います。

    なお、海外の文献を調べていけば見つかると思いますが、/MT オプションを検証された情報もあります。
    http://www.demartek.com/Demartek_Presenting_RMWTUG_March_2011-03.html

    この記事ではローカルでの転送および、ギガビット以上の環境におけるネットワーク転送について検証されており、/MT オプションの効果があることが実証されています。38GB のデータ転送(P.7 の棒グラフ、1GbE Website)の数値を見る限り、91Mbps が 480Mbps ほどに改善しているのでしょうか。
    ただ、この改善後の数値は明らかに、100Mbps のネットワークでは期待できる結果ではありません。
    よって、伝送経路と言える、ネットワーク環境によっては、/MT オプションの恩恵を受けられない可能性が見えてくるわけです。

    2015年6月12日 15:39
  • 確かに、マルチスレッド化で速くなるかと言われると疑問があります。
    マルチスレッドはオーバーヘッドが伴い、余計な処理が含まれますから。
    一般論ではトータルの処理時間は多くなる事が多いとも聞きます。

    但し、これは、その処理を単独に見た場合で、
    スレッドが複数になれば、OS 配下でタイムスライスされた個々のスレッドに処理が回って来る期間が短縮出来ます。

    そういうのはcpuバウンドの話。

    io処理の性能はアクセスをランダムでなくシーケンシャルにすること。

    記事を探すと、ファイルごとにスレッドを分けて多重化するから速いなんて書いてあるものがあったけど、そんなことしたら、折角のシーケンシャルがランダムになってとんでもない。

    2015年6月12日 15:57
  • Azulean さま 有益な情報をありがとうございます。

    機器および機器間の環境に応じて、マルチスレッド化が有益になると理解しました。

    今回のご質問では、コマンドのオプションによるマルチスレッド化ではなく、
    他の環境要因にボトルネックがある可能性を考えていらっしゃるのですね。
    2015年6月13日 0:48
  • ウィンドウズスクリプトプログラマ さま 拝見しました。

    確かに、闇雲にマルチスレッド化が速くなる類の記事は ありますね。

    仰られる様に、マルチスレッド化された Robocopy も、ファイル群をコピーする上では、
    ランダムでなくシーケンシャルに書き出していますね。 シーケンシャルの方が速いですから。 
    いい機会を戴けました。
    2015年6月13日 1:00
  • SSDやRAID向けの機能では。5スピンドルのRAIDなら5か10多重とか。
    2015年6月13日 11:01
  • 皆様

    ご教示頂き、また参考情報を頂きありがとうございます。

    現在検証できることとして、
    コピー元とコピー先の間のネットワークが100Mbpsでしたので、
    同じギガビットハブに接続してみました。
    コピー元とコピー先の内容は同じ状態(全てスキップ)で検証しました。
    処理時間は 23秒 → 17秒 に短縮されましたが、
    /MTの有り無しで時間の差はありませんでした.
    また、スレッド数を2→4と増やしても変化はありませんでした。

    2015年6月16日 6:19