.png)
Windows 8.1 で、Robocopy を使用して 2 台のサーバーのデータを専用 PC のストレージ スペースに保存しています。データ量は 4,110 個のフォルダー内の 147,314 個のファイル (66,841,845,760 バイト) です。
関係する 3 台の PC はすべて、4 コアの i7 CPU を搭載し、1 Gb ネットワークに接続されています。ターゲットのストレージ スペース (D: にミラーリングおよびストライプ化) は、4 x 4 TB JBOD ケースを使用して実現されています。
CPU の 4 つのコアとハイパースレッディングにより、Robocopy スイッチ /MT:8 が最適に機能し、8 スレッドを超えるとスレッド管理の恩恵を受けられなくなるため過剰になると予想していました。
これをテストしました。4 番目のテスト シリーズのデータをここに示します (期間は mm:ss 単位)。
1 thread: 59:19
2 threads: 39:12
4 threads: 29:13
8 threads: 24:36
16 threads: 24:19
32 threads: 24:27
確かに、16スレッドを使用する数秒は無視できるほど小さいですが、彼らは一貫しているすべてのテスト シリーズで、つまり、16 スレッド未満のテストで負荷作業が増えたためではありません (4 つのテスト シリーズすべてでこれが当てはまらない限り)。また、32 スレッドはほとんどの場合、8 スレッドよりも少し高速であることにも注意してください。
質問: 4 つのハイパースレッド コアを備えた i7 で 8 つのスレッドよりも 16 のスレッドを使用する方が効率的である技術的な理由は何ですか?
答え1
TL;drバージョン: Handbrakeを使用してビデオをトランスコードするなど、CPUを非常に集中的に使用する場合は、CPUよりも多くのコアを使用することは望ましくありません。作業を行う場所がなくなるためです。この場合、ほとんどのスレッドが読み取りまたは書き込みを待機して90%の時間を費やすため、スレッドの数を増やすことは効果的です。のために反対するよりも、あなたに賛成する。
ファイルのコピーは、特に CPU に依存するタスクではありません。コアの数を増やすと、他のタスクがコピー ツールをブロックするのを防ぐのに役立ちますが、各スレッドが各コアで 100% 近く実行される可能性は低くなります。
各コピー スレッドはハード ディスクに読み取り要求を送信し、読み取り要求が満たされるのを待機している間はスリープ状態になります。回転する Rust ディスクのシーク時間は通常 9 ミリ秒で、CPU の観点からは実質的に永遠に相当します。コピー タスクは単に「準備はできましたか?」と尋ねながら回転して CPU サイクルを無駄にすることはありません。そうすると、そのスレッドが 100% CPU でロックされ、リソースが無駄になります。そうではなく、スレッドが読み取りを発行し、読み取りが完了してデータが次のステップの準備ができるまでスレッドがスリープ状態になります。
その間に、別のスレッドも同じことを行い、読み取りがブロックされてスリープ状態になります。これは 16 個のスレッドすべてで発生します。(実際には、読み取りと書き込みは同期が取れなくなるためランダムなタイミングで発生しますが、その意味はわかります)
スレッドの 1 つにデータが準備できたら、Windows はそれを再スケジュールし、書き込み処理を開始します。スレッドに関する限り、プロセスは同じです。「このデータをファイル x の場所 y に書き込む」と指示すると、Windows はデータを取得してスレッドのスケジュールを解除します。Windows はバックグラウンドで作業を行い、ファイルの場所を特定し、データを移動します (ネットワークを経由する可能性があるため、遅延が数ミリ秒増加します)。書き込みが成功すると、スレッドに制御が返されます。
1 つのスレッドが CPU コアで常に消費されることはないため、CPU の数よりも多くのスレッドがあっても問題にはなりません。問題になるほど長く起動しているスレッドはありません。
多数の他のスレッドが実行されている単一の CPU しかない場合は、CPU でボトルネックが発生する可能性がありますが、このようなワークロードを持つマルチコア システムでは、CPU に問題があるとは考えられません。
ハードドライブのパフォーマンスがボトルネックになり、ドライブの読み取りまたは書き込みバッファのキューの深さに達している可能性が高くなります。より多くのスレッドを使用すると、何かディスクでもネットワークでも、その限界まで到達する必要があります。最適なスレッド数を見つける唯一の方法は、実際に実行して実験してみることです。
SSD から SSD へのコピー機能を備えたシステムでは、回転する Rust HDD からファイルをコピーし、ネットワーク経由でプッシュして回転する Rust に書き込むよりも遅延が少ないため、スレッドの数が少ない方がよいと思われますが、その推測を裏付ける証拠はありません。