我有4个NetApp 2240-4文件头。 他们是一个单一的底盘'在一个盒子集群'，所以两个单独的单位。
在过去的几天里，几乎在同一时间 – 他们都开始logging很多低水位的一致性点。
运行wafl_susp -w使cp_from_low_water以10 / sec或更高的速率计时。 在这之前，他们几乎完全是cp_from_timer ，每10秒左右一次。
我的两个盒子都没有响应，并重新启动，问题现在又一次。 我不是100％确定这是相关的，但对于一个罪魁祸首似乎是合理的赌注。
另外两个 – 完全闲置，因为它们有一个基本的操作系统，还有几个vfiler – 没有别的。 但是 – 低水位，表明由于某种原因，它们将耗尽内存。 我只能假设某种拒绝服务条件正在发生（也许'失败的SSHlogin'？）。
任何人都可以提供如何解决这个问题的见解？ 特别是从NetApp的angular度来看，我正在寻找一些关于如何提取我的记忆的提示。
打开一张票 – 这是一个迹象表明， 系统内存不足 ，如果没有做任何工作，你仍然有箱子没有反应，有一些棘手的事情发生。 我已经在线上检查了内部存储器的使用情况，但是这不是客户应该自己做的。 您需要使用priv set命令并检查正在运行的进程。
案件与供应商就问题打开。
低水位标记CP是内存耗尽的结果:( 供应商链接）
CP由低水位引起的; 可用于常规内务处理任务的内存量足够低，因此启动CP以释放更多内存是理想的
为了与供应商接口，我们运行了一个“perfstat” – 一个NetApp可下载的工具，允许提交性能相关的支持信息。 这导致我们发现缺陷ID 697790 （需要支持login），出现在我们所使用的代码版本上，在ONTAP 8.2.3中修复
特别是在LDAP身份validation失败的特定情况下会发生内存泄漏。 因为所有4个主机都使用相同的帐户，并且因为在某个时候locking已经绊倒了，他们都经常荒谬地失败。 （特别是非常低的内存系统首先）。
我已经看到了其他系统，这个bug已经存在，并且有一些迹象表明，但是即使在系统正常运行时间超过700天的情况下，也发生了微不足道的事情。
一般来说（并且有一个警告，即'diag'命令有潜在的危险，所以应该在不与供应商交谈的情况下非常小心地执行） – 我们可以通过查看mem_stat来识别问题 – 第二列是'字节'，然后查找'SASL'。
1306719 5268691008 maytag.ko::sasl_client_new+149
我不知道问题出现在什么层面，我正在等待系统再次崩溃检查。 但是，build议超过5％的内存使用率，你应该考虑采取行动。 重新启动修复程序，代码更新也是如此。
我现在捕获cp_types和内存占用作为我的监测制度的一部分，所以我可以观察到它发生。 还要更积极地发现LDAP帐户locking。