NetApp 文件管理器 - 大量“低水位線”CP 在空閒文件管理器上觸發
我有 4 個 NetApp 2240-4 文件頭。它們是單個機箱“盒中的集群”，因此是兩個獨立的單元。
在過去的幾天裡，幾乎在同一時間——他們都開始記錄很多低水位線一致性點。
跑步
wafl_susp -w讓我cp_from_low_water以 10/秒或更高的速度計時。在此之前，它們幾乎完全cp_from_timer以每 10 秒左右 1 次的速度出現。我的兩個盒子沒有響應並重新啟動，現在問題又出現了。我不是 100% 確定這是有關聯的，但對於罪魁禍首來說，這似乎是一個合理的賭注。
另外兩個 -完全空閒，因為它們有一個基本作業系統和幾個 vfiler - 沒有別的。但是 - 低水位線表明它們由於某種原因記憶體不足。我只能假設正在發生某種拒絕服務的情況（也許是“失敗的 SSH 登錄”？）。
誰能提供有關如何解決此問題的見解？特別是從 NetApp 的角度來看，我正在尋找一些關於如何提取佔用我記憶的內容的提示。
打開一張票 - 這表明系統記憶體不足，如果沒有完成任何工作並且您仍然有盒子沒有響應，那麼就會發生一些麻煩事。我之前已經通過線上支持完成了檢查內部記憶體使用的過程，但這不是客戶應該自己做的事情。您需要使用
priv set命令並檢查正在執行的程序。
與供應商就問題打開的案例。
Low Water Mark CP 是記憶體耗盡的結果：（供應商連結）
低水位線引起的CP；可用於日常管理任務的記憶體量足夠低，因此啟動 CP 以釋放更多記憶體是理想的
為了與供應商互動，我們執行了一個“perfstat”——一個允許送出與性能相關的支持資訊的 NetApp 可下載工具。這導致我們發現錯誤ID 697790（需要支持登錄），出現在我們使用的程式碼版本上，已在 ONTAP 8.2.3 中修復
特別是在 LDAP 身份驗證失敗的特定情況下的記憶體洩漏。因為所有 4 台主機都使用同一個帳戶，並且因為在某些時候鎖定已經觸發，所以它們都經常出現荒謬的故障。（並且首先是記憶體非常低的系統）。
我查看了其他存在此錯誤的系統，並且有一些跡象表明它正在發生，但即使在正常執行時間超過 700 天的系統上也發生了微不足道的數量。
一般來說（需要注意的是，使用“診斷”命令可能存在危險，因此在不與供應商交談的情況下應格外小心）——我們可以通過查看來辨識問題
mem_stat——第二列是“字節”並尋找“薩爾’。1306719 5268691008 maytag.ko::sasl_client_new+149我不知道問題出現在哪個級別 - 我正在等待系統再次崩潰以進行檢查。但建議您應該考慮採取行動，超過 5% 的記憶體使用率。重新啟動修復，程式碼更新也是如此。
我現在正在擷取 cp_types 和記憶體佔用作為我的監控機制的一部分，所以我可以觀察到它的發生。在發現 LDAP 帳戶鎖定方面也更加積極主動。