我有 4 个 NetApp 2240-4 文件管理器头。它们是单机箱“盒内集群”，因此是两个独立单元。
在过去的几天里，大约在同一时间 - 他们都开始记录大量低水位一致性点。
跑步wafl_susp -w让我的cp_from_low_water跑步频率达到每秒 10 次或更高。在此之前，它们几乎完全cp_from_timer以每 10 秒 1 次左右的速度运行。
我的两个盒子已经失去响应并重新启动，现在问题又消失了。我不能 100% 确定这是否有关，但似乎可以合理地推断出罪魁祸首。
另外两个是完全地空闲，因为他们有一个基本操作系统和几个 vfiler - 仅此而已。但是 - 低水位线表明他们由于某种原因内存不足。我只能假设发生了某种拒绝服务情况（也许是“SSH 登录失败”？）。
有人能提供一些关于如何解决此问题的见解吗？特别是从 NetApp 的角度来看，我正在寻找一些关于如何提取占用内存的内容的提示。
答案1
打开一张票——这表明有一个系统内存不足，如果几乎没有完成任何工作，但仍然有盒子没有响应，那么一定有什么问题。我之前曾与在线支持人员一起检查过内部内存使用情况，但这不是客户应该自己做的事情。您需要使用命令priv set并检查正在运行的进程。
答案2
与供应商就该问题展开了诉讼。
低水位标记 CP 是内存耗尽的结果：(供应商链接)
低水位标记导致的 CP；用于日常管理任务的内存量足够低，因此最好启动 CP 来释放更多内存
为了与供应商进行交互，我们运行了“perfstat”——一个 NetApp 可下载的工具，允许提交与 perf 相关的支持信息。这导致我们发现了 bugID 697790（需要支持登录），存在于我们使用的代码版本中，已在 ONTAP 8.2.3 中修复
具体来说，在 LDAP 身份验证失败的特定情况下会发生内存泄漏。由于所有 4 个主机都使用同一个帐户，并且由于在某个时刻锁定被触发，它们都异常频繁地失败。（而且首先是内存非常低的系统）。
我查看了存在此错误的其他系统，并且有一些发生此错误的迹象，但即使在正常运行时间超过 700 天的系统上，也只发生了微不足道的情况。
一般来说（但需要注意的是，“diag”命令的使用具有潜在危险，因此在使用时应极其小心，且不要与供应商沟通） - 我们可以通过查看mem_stat第二列“字节”并查找“sasl”来识别问题。
1306719 5268691008 maytag.ko::sasl_client_new+149
我不知道问题出现在什么级别——我正在等待系统再次崩溃以进行检查。但建议当内存使用率超过 5% 时您应该考虑采取行动。重新启动可以解决问题，代码更新也可以。
现在，我正在捕获 cp_types 和内存占用量，作为我监控机制的一部分，这样我就可以观察到它的发生。同时，我也会更积极主动地发现 LDAP 帐户锁定。