同一伺服器上的 NFS/CIFS 目錄之間的複製速度緩慢

Question

嗯……我確實注意到了一些問題，我想我發現了一兩個確鑿的證據。但是，首先我會問幾個問題並對您可能的答案做出假設。我將提供一些乍看之下似乎無關緊要的數據，但我保證，它將值得一讀。所以，請稍等...:-)

我假設到 raid10，您總共有四個驅動器條帶+冗餘。
並且，您正在使用 Linux autoraid（相對於硬體 raid 控制器）。
我還假設所有 SATA 連接埠都可以以全傳輸速度相互獨立地進行雙向傳輸，並且所有 SATA 連接埠都具有相同的高速。也就是說，如果您有一個 SATA 適配器/控制器，它完全能夠以額定速度運行與其連接的所有磁碟。
我還假設您擁有最新的 SATA 規格驅動器 + 控制器。即 6.0Gb/s。那是 600MB/秒。保守一點，假設我們得到了一半，即 300MB/秒
客戶端到伺服器受 NIC 限制（100MB/s），因此無法對磁碟機施加足夠的壓力。
為了比 NIC 更快，在進行 NFS 到 NFS 時，我假設您使用的是 localhost，以便您可以超越 NIC 限制的速度（我認為您說您做了綁定以表明這不是問題））

問題#1。您報告的即使是快速本地到本地的傳輸速率似乎也很低。對於這麼快的磁碟，我預計速度會超過 150MB/s。我有一個 3 磁碟 raid0 系統，只能實現 3.0Gb/s [適配器限制]，但條帶化速度可達 450 MB/s。您的磁碟/控制器的速度是我的速度的 2 倍，因此，我預計（由於條帶化）您的本地到本地速度將達到 300MB/秒，而不僅僅是 150MB/秒。或者，甚至可能是 600MB/秒 [減去 FS 開銷，為了討論起見，可能會將其減半]

從您的 zpool 資訊中，我注意到您的磁碟配置是 Western Digital，它是：

鏡像-0
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0
鏡像-1
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0

現在讓我們將其與您的 iostat 資訊進行比較。對於所有測試來說，在所有驅動器上都有 iostat 資訊可能會很好，但我相信我可以根據您提供的資訊來診斷問題
sdb 和 sdd 已滿
正如您所指出的，這是奇怪的。我希望全部驅動器在 raid10 中具有平衡的使用/統計數據。這是[我的]確鑿證據。
將兩者結合起來。已達到最大容量的驅動器的型號與未達到最大容量的驅動器的型號略有不同。我認為 zpool 順序是 sda/sdb sdc/sdd [但可能會顛倒]
sda/sdc 是 68AX9N0
sdb/sdd 是 68EUZN0

問題#2。從 WD20EFRX + 68AX9N0 + 68EUZN0 的Google搜尋中，我找到了這個頁面：http://forums.whirlpool.net.au/archive/2197640

看起來 68EUZN0 驅動器可以在大約 8 秒後停止轉動，而另一個驅動器對此更聰明 [反之亦然]。

因此，考慮到 NFS 緩存 + FS 快取 + SSD 緩存，底層驅動器可能會閒置並停止磁頭。我的猜測是，NFS 的額外快取層導致了它的崩潰。

您可以透過改變 FS 同步選項來測試這一點，也許同步比非同步更好。另外，如果可以的話，我會在關閉 SSD 快取的情況下重新執行測試。這個想法是為了確保停車不是發生並查看結果。

正如網頁上提到的，有一些實用程式可以調整停車延遲間隔。如果可以選擇，請務必進行徹底研究。

更新：

您的問題可以被視為透過儲存轉送[保證交付]網路的吞吐量問題。注意，我是不是談論 NIC 或同等設備。

考慮 I/O 操作就像一個包含儲存在結構中的請求（例如讀/寫、buf_addr、buf_len）的資料包。此請求資料包/結構在各個快取層之間傳遞：NFS、ZFS、裝置驅動程式、SATA 控制器、硬碟。在每個點，您都有該層的到達時間，以及請求轉送到下一層時的出發時間。

在這種情況下，實際發生傳輸時的實際磁碟傳輸速度類似於連結速度。當大多數人考慮磁碟時，他們只考慮傳輸速度，而不考慮傳輸實際啟動的時間。

在網路路由器中，封包到達，但它們並不總是立即轉發，即使出站鏈路暢通也是如此。根據路由器策略，路由器可能會將封包延遲一點，希望有更多封包從其他來源到達（如果是UDP，則從相同來源到達），因此路由器可以將較小的封包聚集成一個大封包，以便更有效地在出站鏈路上傳輸。

對於磁碟，這種「延遲」可以透過給定的 FS 層的快取策略來表徵。換句話說，如果請求在時間 T 到達某一層，則它可以在 T+n 離開/到達，而不是在 T+1 離開該層並在 T+1 到達下一層。 FS 快取層可能會執行此操作，以便它可以進行尋道順序最佳化/排序。

您看到的行為與由於擁塞而減少視窗的 TCP 套接字非常相似。

我認為分開測試很重要。現在，你正在閱讀和寫作。而且，您不知道哪個是限制因素/瓶頸。我認為將測驗分為讀或寫會很有幫助。一個不錯的基準測試程式可能會做到這一點。我提倡的是一個更複雜的版本[這些只是粗略的例子，而不是要使用的確切參數]：

對於寫入，時間 dd if=/dev/zero of=/whatever_file count=64g
對於讀取，時間 dd if=/whatever of=/dev/null count=64g

之所以選擇 64GB，是因為它是實體 RAM 的 2 倍，並且消除了區塊快取效應。在測試之間執行同步命令。

將其應用於本地 FS 並在 NFS 上重複。

另外，請執行讀對每個 /dev/{sda,sdb,sdc,sdd} 進行測試

在這些測試期間進行 iostat。

請注意，在實體原始磁碟上進行讀取測試可以為您提供硬體實際運行速度的基線/最大值。原始設備讀取應接近驅動器傳輸規格的最大能力。硬碟的預期寫入速度應該相似。如果沒有，為什麼不呢？所有磁碟應以大致相同的速度進行測試。我在這裡要解釋的是為什麼在之前的測試中只有兩個磁碟達到最大容量。

計算一下，如果使用 32GB，假設最大傳輸速度為 600MB/秒，則填入/刷新至少需要 50 秒。那麼，公園超時設定為多少呢？

另外，您可以透過 mem= boot 參數減少核心允許的物理記憶體數量，從而稍微改變一下情況。試試看mem=8g之類的東西，看看有什麼效果。還有一些 /proc 條目可以調整區塊層快取刷新策略。

另外，我的 FS 是 ext4 並使用 noatime 掛載。您可能需要考慮zfs set atime=off ...

另外，請查看系統日誌。有時，驅動器會報告偵測錯誤，系統會將其重新配置為使用較低的傳輸速度。

另外，請查看磁碟機的 SMART 資料。你看到什麼不尋常的地方了嗎？在給定驅動器上進行過多的軟重試（例如）。

正如我所說，本機磁碟效能遠低於我的預期。我認為在使用 NFS 處理整個系統之前需要先解決這個問題。如果所有的 raid 磁碟都有均衡的使用率並且在大致範圍內，我就不會那麼擔心了。

我的系統 [也有 WDC 磁碟] 未配置 NFS（我經常使用 rsync）。接下來的 1-2 天我有一些迫切的事情要做。之後有時間我會試試看[我自己也很好奇]。

更新#2：

很好地解決了 ZFS 不平衡問題。這有助於解釋我的“問題#1”。它可能如果重新平衡操作在某種程度上混淆了 NFS 的延遲/計時，從而導致「TCP 視窗/退避」行為，那麼也可以解釋 NFS 的脆弱性——雖然機率不是很高，但仍然是有可能的。

通過 rsync 測試，不需要/不想使用 NFS。如果您可以 ssh 進入伺服器，則 rsync和NFS 是多餘的。使用NFS，只需使用cp等即可。即使沒有 NFS 掛載，這也可以工作[這是我使用的 rsync 配置]：

導出 RSYNC_SSH="/usr/bin/ssh"
導出 SSH_NOCOMPRESS=1
rsync /wherever1 伺服器：/zfsmount/whatever

執行此 localhost 或 bond 可能會獲得您期望的效能（沒有 ZFS 不平衡問題）。如果是這樣，它顯然將問題範圍縮小到 NFS本身。

我仔細閱讀了 NFS 的一些核心原始碼。從我所看到的來看，我不喜歡我所看到的關於及時性的內容。 NFS 始於 80 年代，當時連結速度很慢，因此它[仍然]有大量程式碼來嘗試節省 NIC 頻寬。也就是說，只有在絕對必要時才「承諾」某項行動。不一定是我們想要的。在我奇特的網路路由器策略類比中，NFS 的快取似乎是具有「T+n」延遲的快取。

我建議您盡一切努力禁用 NFS 的快取並讓它盡快將其請求傳遞給 ZFS。讓 ZFS 成為智慧管道，NFS 成為「啞管道」。 NFS 快取本質上只能是通用的（例如，它甚至不知道後備儲存是 RAID，也不知道它所安裝的基本 FS 的特殊特性）。 ZFS 對 RAID 及其組成磁碟有深入的了解。因此，ZFS 的快取可以更聰明地進行選擇。

我想說嘗試讓 NFS 進行同步掛載——這可能會成功。另外，我看到了一些關於 noatime 的內容，所以也打開該選項。可能還有其他 NFS 調整/安裝選項。希望，如果 NFS 是常見的嫌疑對象，那麼它可以重新配置以使其工作得足夠好。

另一方面，如果沒有任何選擇可以讓 NFS 屈服，那麼透過 ssh 進行 rsync 是否是一個可行的替代方案？實際用例是什麼？看來您正在使用 NFS 作為需要高效能的大批量傳輸的管道（相對於[比如說]只是作為用戶主目錄的自動掛載點）。這是用於客戶端備份到伺服器之類的事情嗎？

Answer 1