複製文件夾中數十萬個文件的 TB 速度很慢
我目前正在執行 FreeNAS 並在 Windows 機器上使用 SMB 3 來複製包含 80000 多個文件的文件夾，每個文件大約 35MB。這是配置
自由NAS
- 2x40Gbps 連接綁定
- 啟用 SMB 3.1 的連接 SMB 共享
- 1 個至強 8 核，512GB 記憶體
- 400TB 儲存 RAID Z1 使用 4TB 驅動器獲得更多 iops
- 每個 RAID 組 23 組，每組 5 個驅動器
- 3 個 LSI 3008 SAS 3.0 12Gb/s 主機匯流排適配器
- 可以在 thinkmate.com 上使用超級儲存伺服器 6048R-E1CR72L 作為基礎進行類似配置，然後添加到擴展機箱
- 啟用巨型幀
- 在傳輸期間 CPU 使用率約為 50%
- 在傳輸期間 RAM 使用率為 60%
工作站
- 視窗 10 專業版
- i7 3.6Ghz 和 16GB 記憶體
- 512GB m.2 驅動器
- PCI 3.0 16x 插槽中的 40Gbps 卡
- 啟用巨型幀
- TCP 解除安裝已禁用
- 外部 RAID 0（3 或 4 個磁碟）驅動器通過 USB-C 連接
- 傳輸期間的 CPU 使用率為 20%
- 傳輸期間的 RAM 使用率為 15%
所以我有這些 RAID 0 驅動器，每個驅動器大約有 4TB 的文件，每個文件是 35MB。每個文件夾大約有 80000 個文件。8 個同時傳輸，跨 8 個工作站。
當我使用 robocopy 複製文件時。我得到大約 1.8Gbps 的傳輸速度。然後隨著時間的流逝，副本越來越深入到那些速度下降到大約 600Mbps 的文件中。無論我是否在 robocopy 上使用 /MT:10 of /MT:1，都會發生這種情況。EMCopy 也好不了多少，freefilesync 想在大約 3 小時後死掉。我希望它至少保持穩定在 1.8Gbps，而不是不斷下降。在這些傳輸過程中瀏覽工作站上的共享也變得無響應。有沒有其他人經歷過這個？
好的，看起來問題現在已經解決了。這是解決方案。
在裡面
/etc/samba/smb-shares.conf.local此行已添加到我們正在使用的共享中
case sensitive = yes現在我們以穩定的 200MBps 傳輸。雖然不是理想的速度，但它並沒有隨著時間的推移而降低速度。這解決了速度下降的問題。
傳輸速度慢的根本原因可能是工作站 M2 驅動器需要執行大量隨機讀取。
速度快的 NVMe M2（我認為您最有可能使用）被宣傳為具有高達多個 GB/sr/w 的速度。對於大文件的順序讀取確實如此，但在您的情況下，您將改為隨機讀取。普通消費者/專業消費者 NVMe M2 SSD 的隨機讀取速率範圍從 70MB/s 到 110MB/s，即在您的 600Mbps 速率範圍內。對 SSD 的評論通常會包括隨機讀取速度結果，這就是我得到這個範圍的地方。
有一些 SSD，例如 Intel Optane SSD，可以提供大約 500MB/s 的隨機讀取速度。
此外，您聲明您通過 USB-C 連接驅動器。根據使用的技術（USB3.0、3.1、3.2 或 Thunderbolt），此連接也可能會導致速度變慢。內部 NVMe M2 驅動器（或其他更快的基於 PCI-e 的驅動器）可能會解決問題。
要證明或使我的假設無效，您可以使用 Windows 10 任務管理器或性能監視器。任務管理器將為您提供驅動器繁忙程度的百分比。如果有問題的驅動器處於 100% 或任何高於 80% 的位置，那麼它們可能會限制速度。另一方面，如果它是空閒的，那麼它不是限制性的。免責聲明：我不知道 Windows 任務管理器的繁忙百分比有多可靠，尤其是對於外部驅動器而言。
如果事實證明源端的驅動器根本不忙，您可能需要檢查目標端並查看驅動器在那裡的工作情況（您可以使用 iostat 工具）。
如果這些都對您沒有幫助，因為您能夠將源端和目標端的驅動器都排除為問題的根本原因，那麼我建議您從基本的故障排除步驟開始。例如，您可以傳輸一個大文件並查看此傳輸是否受到相同的限制。您可以反轉傳輸方向並將一些小文件複製回工作站。如果只是反轉導致更快的速度，那麼也許有一個組件僅在讀取時限製而不在寫入時限制，反之亦然。
或者嘗試通過直接連接設備來排除某些組件，中間沒有額外的開關，或者您可以從場景中刪除任何東西進行測試。