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

質問
-
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 -
ShiroYuki_Mot 様
返信頂きありがとうございます。
> 従って、実データの転送を伴わない、属性変更ではマルチの恩恵を受けていない気がします。
ということは、属性のコピー(/COPY:DATS)もマルチスレッドにならないという推測でしょうか?
次に。。。 気になったので、データ転送がマルチスレッドになるのか、空のコピー先を用意して試してみました。
コピー元とオプションは同じです。
結果は下記でした。
/MT無し 28分
/MT:2 23分
/MT:8 23分
/MT:128 23分
ROBOCOPYを実行しているPCのスペックも関係すると思いますが、
2と8でここまで変化が無いものなのでしょうか??
2015年6月12日 9:23 -
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:23
2015年6月12日 14:06 -
私も同意見で、マルチスレッドにすれば速くなる論理はないと思います。
I/O、つまり、ネットワークの転送(やディスク読み書き)がボトルネックである可能性が高く、CPU をいくつ使おうが、改善しません。
並列に実行すると、逆に完了が遅くなる可能性すらある話だと思います。全部転送すると仮定した場合、14GB = 14,336MB が 23 分、分あたり 623MB、秒あたり 10.38MB、ビットレートに直すと 83.11Mbps ぐらいですかね?
(ファイルの比較処理において、CPU パワーはそんなにいらず、I/O がコストの大半を占めると考えます。「マルチスレッドによる並列化」はあくまで CPU による演算量をコアごとに振り分けることで時間を短縮するだけであり、I/O を効率よくできる処理できる仕組みではありません)
100Mbps のネットワークならそんなものではないかと思いますが、ギガビット(1,000Mbps)であるとか、ディスクの転送速度も十分速いとか、疑うに足る根拠をお持ちなのであれば、その根拠も明示してください。
- 編集済み AzuleanMVP 2015年6月12日 14:27
2015年6月12日 14:24 -
ウィンドウズスクリプトプログラマ さま 拝見しました。
確かに、マルチスレッド化で速くなるかと言われると疑問があります。
マルチスレッドはオーバーヘッドが伴い、余計な処理が含まれますから。
一般論ではトータルの処理時間は多くなる事が多いとも聞きます。
但し、これは、その処理を単独に見た場合で、
スレッドが複数になれば、OS 配下でタイムスライスされた個々のスレッドに処理が回って来る期間が短縮出来ます。
3セット以上は意味がない ならば、Windows7 で robocopy をマルチスレッド化する際にそうしている筈です。
仰る様に、IO の実際のファイル操作は OS 内部のファイルシステムなので、 ... 複雑ですね。2015年6月12日 14:45 -
IO がボトルネックになる点は理解出来るのですが、
ストレージの速度、伝送経路の速度、CPU など、様々な組み合わせがある中、有効に働く場合もあれば、効果がない場合、悪化する場合と様々なパターンがあることが予想されるわけですから、robocopy でマルチスレッド対応した理由を求めることは、問題解決に結びつかないと私は思います。
Windows7 で robocopy をマルチスレッド化した訳で、 何かメリットを見出したからでは無いのでしょうか?。
その何か? が分りません!。なお、海外の文献を調べていけば見つかると思いますが、/MT オプションを検証された情報もあります。
http://www.demartek.com/Demartek_Presenting_RMWTUG_March_2011-03.htmlこの記事ではローカルでの転送および、ギガビット以上の環境におけるネットワーク転送について検証されており、/MT オプションの効果があることが実証されています。38GB のデータ転送(P.7 の棒グラフ、1GbE Website)の数値を見る限り、91Mbps が 480Mbps ほどに改善しているのでしょうか。
ただ、この改善後の数値は明らかに、100Mbps のネットワークでは期待できる結果ではありません。
よって、伝送経路と言える、ネットワーク環境によっては、/MT オプションの恩恵を受けられない可能性が見えてくるわけです。
- 編集済み AzuleanMVP 2015年6月12日 15:56
2015年6月12日 15:39 -
確かに、マルチスレッド化で速くなるかと言われると疑問があります。
マルチスレッドはオーバーヘッドが伴い、余計な処理が含まれますから。
一般論ではトータルの処理時間は多くなる事が多いとも聞きます。
但し、これは、その処理を単独に見た場合で、
スレッドが複数になれば、OS 配下でタイムスライスされた個々のスレッドに処理が回って来る期間が短縮出来ます。そういうのはcpuバウンドの話。
io処理の性能はアクセスをランダムでなくシーケンシャルにすること。
記事を探すと、ファイルごとにスレッドを分けて多重化するから速いなんて書いてあるものがあったけど、そんなことしたら、折角のシーケンシャルがランダムになってとんでもない。
2015年6月12日 15:57