首先，很抱歉發布一個明顯的研究問題。我知道這是一個壞習慣，但我希望我仍然在這裡得到幫助，因為我做了大量研究，但找不到任何答案。
這設想是這樣的：NFS 用戶端在 NFS 伺服器上寫入 50GB 的單一檔案。寫入 4GB 後，平均速率為 125 MByte/s，降至 12MByte/s。
問題: 怎麼解釋呢。
這給定回答問題是這樣的：在寫入 4GB 後，伺服器不回應 COMMIT，並且客戶端定期發送 COMMIT，直到伺服器回應它，因為客戶端想要清空其快取。在該時間段內，資料速率下降到最慢元素的水平。
我能找到的關於 COMMIT 過程的所有解釋都是這樣的：
客戶端寫入數據，當資料傳輸到伺服器時，客戶端發送COMMIT。伺服器將資料寫入穩定儲存並使用 verf-Cookie 回應 COMMIT。如果 cookie 與用戶端 cookie 沒有不同，則用戶端可以清空其快取。
所以這裡是我的問題：如果伺服器不透過發送 verf-cookie 來回應 COMMIT-Procedure，客戶端是否會定期發送 COMMIT，且資料速率會顯著下降？如果是，數據速率會下降到什麼水平。我無法從數據速率下降到什麼水平的答案中得出結論。
答案1
我認為正在發生以下情況：
客戶端所傳送的資料寫入伺服器端的FS快取中。一旦發送 COMMIT 請求，該資料就開始刷新到持久性儲存（DISK）。根據伺服器的磁碟效能，這可能需要一些時間。假設磁碟效能為 300MB/s。刷新 4GB 需要 13 秒。如果該時間長於 NFS 逾時，則用戶端可能會傳送另一個 COMMIT 請求，並假設第一個請求遺失。 COMMIT/WRITE 驗證程序用於確保伺服器在此操作之間不會重新啟動。
在這種情況下，你可以這樣做：
- 透過指定增加客戶端上的 NFS 逾時時間=安裝選項。雖然這只會使固定重試 COMMIT。
- 告訴伺服器儘早開始刷新資料並避免日誌延遲。
使用
sysctl -w vm.dirty_background_ratio=0
sysctl -w vm.dirty_ratio=0
sysctl -w vm.dirty_background_bytes=67108864
sysctl -w vm.dirty_bytes=536870912
應根據伺服器 IO 效能和網路整體情況調整大小。
控制核心何時開始將資料刷新到伺服器上的磁碟並發送到客戶端的伺服器。
注意：此選項是全域的，將影響所有檔案系統。