在 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 個線程將是過度殺傷力。
我測試了這個。我在這裡列出了第四個測試系列的數據（持續時間以 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 上，使用 16 個執行緒比使用 8 個執行緒更有效率的技術原因是什麼？
答案1
TL;dr 版本：如果您正在執行 CPU 密集型操作，例如使用 Handbrake 轉碼視頻，那麼您不會希望使用比 CPU 更多的內核，因為沒有地方可以完成工作。在這種情況下，大多數執行緒將花費 90% 的時間休眠等待更多執行緒工作的讀取或寫入為了你而不是反對。
複製檔案並不是一項特別佔用 CPU 資源的任務。雖然擁有更多核心可能有助於防止其他任務阻塞您的複製工具，但每個執行緒不太可能在每個核心上以接近 100% 的速度運行。
每個複製執行緒都會向硬碟發送讀取請求，然後進入睡眠狀態，等待讀取請求得到滿足。旋轉的 rust 磁碟通常有 9 毫秒的尋道時間，就 CPU 而言幾乎是永恆的，並且複製任務不會簡單地旋轉說“準備好了嗎？”並浪費 CPU 週期。這樣做會將該執行緒鎖定在 100% CPU 狀態並浪費資源。不，所發生的情況是線程發出讀取並且線程進入睡眠狀態，直到讀取完成並且資料準備好進行下一步。
同時，另一個執行緒執行相同的操作，在讀取時被阻塞並進入睡眠狀態。所有 16 個執行緒都會發生這種情況。 （實際上，您的讀取和寫入會在不同步時隨機發生，但您明白了）
一旦其中一個線程準備好數據，Windows 就會重新安排它並開始處理它以供寫入。就線程而言，過程是相同的。它說“將此資料寫入檔案 x 的位置 y”，Windows 取得資料並取消調度執行緒。 Windows 執行後台工作來確定檔案的位置，行動資料（可能透過網路增加更多毫秒的延遲），然後在寫入成功後將控制權傳回給執行緒。
沒有一個執行緒會一直在 CPU 核心上燃燒，因此比 CPU 數量更多的執行緒不是問題。沒有執行緒處於喚醒狀態的時間夠長，不會成為問題。
如果您只有一個 CPU，同時運行許多其他線程，那麼您可能會遇到 CPU 瓶頸，但在具有這種工作負載的多核心系統中，如果 CPU 是問題所在，我會感到驚訝。
您更有可能遇到硬碟效能瓶頸，並達到磁碟機上讀取或寫入緩衝區的佇列深度。透過使用更多線程，您正在推動某物到其極限，無論是磁碟還是網絡，找出最佳線程數的唯一方法就是做你已經做過的事情並進行試驗。
在具有SSD 到SSD 複製功能的系統上，我懷疑線程數量越少可能會更好，因為與從旋轉的rust HDD 複製檔案、透過網路推送並寫入旋轉的rust 相比，延遲會更短，但我沒有證據表明支持這個假設。