我有一個運行 NFS 4 的 CentOS 6.4 檔案伺服器，為幾個 XFS 檔案系統提供服務。有幾十個客戶端連接到它。今天，客戶端的速度慢得像爬行一樣——當從伺服器存取掛載的 NFS 共用時，客戶端會掛起或僅在幾分鐘後回應。在伺服器本身上，我可以毫無問題地存取共享檔案系統。大約四個小時後問題就消失了，但我不知道為什麼 - 請參閱下文。
top顯示了幾個migration進程和xfssyncd進程消耗了異常數量的 cpu，每隔幾秒鐘就會在 0% 和高達 100% 之間跳躍。沒有其他進程明顯活躍。 top 報告的總體 cpu 使用率很低，如下所示：
Cpu(s): 0.0%us, 4.2%sy, 0.0%ni, 95.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
我在網上找不到任何專門討論此問題的內容，除了訂閱者專用部分中的 RHEL 支援條目，但我看不到。
我跑了service nfs restart。然後service nfs status顯示正在運行的守護進程，除了nfsd dead but subsys locked.再次重新啟動後，該問題消失了，nfsd 正在運行，但客戶端仍然掛起。
我嘗試了一些針對 xfssyncd 相關問題建議的方法：
1)mount –o remount /mnt/data在導出的 fs 上。有趣的是，該命令運行大約需要一分鐘，在此期間「瘋狂」進程穩定下來。但是，一旦命令完成運行，進程就會恢復到高 CPU 使用率。
2)echo 720000 > /proc/sys/fs/xfs/xfssyncd_centisecs為了更改xfssyncd 的同步間隔。這並沒有產生任何明顯的差異，這並不奇怪，因為 fs 正忙於 NFS 用戶端，而且問題一定是其他問題。
三週前，我在這台伺服器上遇到了一個問題，其中一個 .nfsNNN 檔案（來自已刪除的檔案仍然打開並正在存取）在客戶端上快速填滿並出現循環錯誤訊息。終止問題進程修復了 NFS 速度減慢的問題。 [然而，幾天後文件伺服器再次變慢，沒有出現這樣的 .nfsNNN 文件問題，我最終不得不重新啟動它。當時我看到一些進程的 cpu 等級不尋常，但沒有註意到它們是什麼，現在也不記得它們是否與當前問題相同。
我今天再次搜尋打開的 .nfsNNN 文件，這些文件可能有問題，但沒有找到。我確實刪除了幾個月前的一些內容，但它們目前沒有被修改，所以認為它們不是問題。刪除這些文件後我發現沒有任何差異。
嘗試上述各種操作後約一個小時，伺服器恢復正常，且migration進程xfssyncd不再具有高 CPU 使用率。我不知道發生了什麼變化，但我想嘗試先弄清楚這一點，因為它似乎可能會再次發生。
感謝您的任何建議。
-M
答案1
我的 RHEL 6.10 也有類似問題。唯一有幫助的似乎是終止 NFS 用戶端上長時間運行的用戶 sftp 進程。這些進程由基於 GUI 的 SFTP 用戶端（例如 WinSCP、Nimble Commander）保持開啟多個小時（> 10 小時）。
監控顯示一些 NFSv3 用戶端活動與該問題相符，但該活動實際上低於其他不會導致問題的客戶端（有 > 100 個客戶端）上的其他典型活動。
實際上也沒有完成很多 I/O。
2019-12-10 更新：根本原因似乎是 NFS 伺服器上的 XFS 配額。使用者主目錄具有配額，軟限制比硬限制低 2 GB。一些用戶嘗試安裝完整的 Anaconda Python，這超出了軟限制。 Anaconda 安裝程式似乎沒有辦法攔截警告，並且不斷下載超過軟限制的檔案。這產生了大量的配額警告，使系統完全陷入困境，並使其反應遲鈍。
我說「似乎」是因為證據是間接的。當使用者嘗試安裝到沒有配額的目錄中時，一切都很順利。