如何修復累積的 NFS DELEG 鎖需要客戶端硬掉電？
我們的舊生產系統有一個數據伺服器和一個計算客戶端，它們通過 NFSv4 進行互動；兩者都在 VMWare 虛擬化上執行。
我們已經確定，隨著計算客戶端軟體的執行，隨著時間的推移，數據伺服器上的 DELEG 鎖的數量（用 來衡量
lslocks | wc）會隨著時間的推移而增加。DELEG READ 鎖的數量可以瞬時飆升至 100,000；從長遠來看，DELEG 鎖的數量會增加。實際上沒有 DELEG WRITE 鎖。當數據伺服器上的 DELEG 鎖數量達到 15,000 左右時，計算客戶端變得幾乎沒有響應；大多數程序處於“D”狀態。負載平均 保持中等，但 CPU 使用率從大約 90% 下降到 10% 或更少。
即使在幾分鐘後終止計算客戶端上的作業也不會減少鎖定計數。從命令行關閉或重新啟動通常會掛起；解除安裝 NFS 文件系統和 /tmp 可能會失敗。
硬重置通常會導致重新啟動時無法掛載 NFS 掛載；但是數據伺服器上的鎖計數會急劇下降。硬斷電加上 2 分鐘的等待將允許 VM 重新啟動，包括所有 NFS 掛載。
數據伺服器正在執行 SLES 12 (
4.1.16-2.g1a0d915-default)；它有 12 個 vCPU 和 128GB 的 RAM，並大量使用 SSD 和 HD 支持的 SAN。nfs-kernel-server 的數據伺服器版本是1.3.0-9.1. 數據伺服器每天計算大約 100k 個數據文件。其中一些文件被伺服器本身覆蓋和重命名，但主文件或主文件的臨時副本應該可用。客戶端程式碼知道這一點，並在需要時進行故障轉移。計算客戶端正在執行 Debian Stable Stretch (
4.9.0-6-amd64)。它有 24 個 vCPU 和 128 GB 的 RAM。nfs-common 客戶端版本是1:1.3.4-2.1. 通過 NFS，讀取這些數據文件，包括每天生成的 100k 文件的活動集以及歷史生成的文件。一個文件可以被多個程序同時讀取。大多數文件由小型 bash 腳本訪問，這些腳本一次訪問 1 或 2 個文件，並重塑數據以供上游使用。這些腳本由 python 和 perl 中的程序呼叫，其生命週期約為數小時。數據伺服器具有如下導出：
/mnt/ssd 172.26.188.199(rw,wdelay,root_squash,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)計算客戶端具有 fstab 條目，例如：
172.26.188.198:/mnt/ssd /mnt/ssd nfs defaults 3 3計算客戶端比數據伺服器具有更直接的架構。執行 SLES 的早期 VM 實例遇到了類似的問題；這促使對作業系統和計算工作進行了全面檢查。這有助於減少但不能消除問題。
下一個明顯的步驟是將現有的數據伺服器移植到新的作業系統，但這是一項繁重的工作，回報不確定。因為該行為跨越兩個執行不同 Linux 版本和不同軟體的不同計算客戶端，我們懷疑問題一定是以下之一：伺服器作業系統或 NFS 版本、客戶端的高頻重疊訪問模式、文件重寫模式數據伺服器（也許如果數據伺服器完全拆分為 NFS 伺服器，則 nfsd 內部狀態將被糾正），NFS 中可能存在的錯誤或我們如何配置它的錯誤。我也不願意忽略我們的乙太網或 SAN 中可能存在的問題，但認為這些目前不太可能。
除了對伺服器進行大修或切換到分佈式文件系統或設置定期重啟間隔之外，還有哪些短期修復可能有助於保持我們數據伺服器上的 DELEG 鎖定計數低？
為了解決這個問題，我們嘗試更改文件伺服器（仍然是 NFSv4）、硬體和核心版本（現在 NAS 上的 linux 4.2.8 從 x86/VMWare/SLES 上的 4.1.16）。儘管發生了這些變化，NFS4 DELEG 鎖的積累仍然發生——大概這是一個根源於在純本地（直接）儲存上工作的軟體結構的問題。最終，我們放棄了 NFSv4，現在使用帶有nolock選項的**NFSv3 ；**出於性能原因，我們還使用 noatime、nodiratime、noacl。鎖不再累積，導致以前看到的災難性減速。