几个月来，我们一直在与特定服务器上奇怪的内存压力问题作斗争。这是 SentryOne 中最后一个事件的样子：
系统内存
SQL Server 内存
内存配置：
- 服务器总内存 - 96GB
- 最大服务器内存 - 84GB
这看起来很奇怪的原因是，如果是外部内存压力，我预计系统内存上的其他类别会在此期间增长，但事实并非如此。
我们在此期间看到的部分情况是查询最终会生成错误的计划并最终导致应用程序出现性能问题。从历史上看，在这种情况下运行 DBCC FreeProcCache 可以缓解压力，但我们仍然不知道原因。我认为计划得到一个糟糕的计划是这个问题的症状而不是原因，但我可能错了。
我们为尝试解决此问题所做的事情：
- 删除了我们认为有问题的 sp 的连接
- 删除了数据库中的重复记录
- 服务器内存增加（我认为我们增加了 16-32 GB）
- 启用内存中的锁定页面
我完全不知道接下来要看什么。我们的架构师认为我们可能需要使用内存来调整一些 VM 设置，但我们还没有做到。
我可以看什么来潜在地解决这个奇怪的内存压力问题？
Jonathan Kehayias 在 SQL SQLSkills.com 上发表了一篇很酷的文章，标题为Wow… 一个错误配置 SQL Server 内存的在线计算器！.
乔纳森在他的文章中写道：
如果您继续使用此示例，那么您最好将 SQL Server 配置为使用 81 GB 的 max_memory 设置运行。
您可以使用以下公式和数据创建一个 Excel 以生成一个漂亮的 SQL Server Max Memory 设置小图。
Excel 工作表以HW 内存(A2) 列开头：
第二列OS Reserved (B2) 的 Excel 公式为：
SQL 内存列(C2) 为：
这将产生以下图表：
可能的解决方案
如您所见，如果您有 96 GB 的 RAM，那么您应该为操作系统保留 15 GB 并将 SQL 内存 (max_memory) 设置为 81 GB。
乔纳森继续在他的文章中解释说......
您的操作系统可能没有足够的内存并且正在从 SQL Server 操作系统中占用内存。
将 max_memory 设置稍微降低到 81 GB 将允许不在 max_memory 设置内运行的操作系统和其他 SQL Server 组件拥有足够的 RAM。
你的旅费可能会改变
我可能对此有误，但我们还是试试吧。也许它会对你有所帮助。
从您提供的屏幕截图中，当您开始遇到性能问题时，它似乎是页面预期寿命坦克。我想您当时看到查询有很长的 PAGEIOLATCH_* 等待？您还提到正在生成错误的计划，并且运行 DBCC FREEPROCCACHE 可以暂时解决问题。对我来说，这听起来像是参数嗅探的典型症状。我猜你有一个查询，当使用错误的参数编译时，会进行表扫描而不是搜索，使用错误的索引或查询计划的形状发生变化。通常，这是一个需要大量 I/O 并且使存储子系统饱和的查询，因此即使是进行键查找的简单查询也会变得很慢。当您遇到性能问题时，我会尝试确定它是哪一个并通过仅删除它的计划来确认。
为了识别有问题的查询，我将只查看那些有很长 PAGEIOLATCH 等待的查询，并在它们快速时比较它们的执行计划。
要解决它，您需要发挥创造力。您可以尝试添加查询提示，在每次执行时强制重新编译，使用计划指南。我在更改基础表的索引和重写有问题的查询方面也取得了成功。很难提出任何具体的建议，因为您现在的问题是确定是什么导致了您的问题。
在运行夜间 SSIS 作业时，我看到过类似的问题，有时 SSIS 内存使用情况对于 Sentryone 来说是不可见的，无论出于何种原因。我会查看 S1 中的事件日历，看看当时正在运行哪些作业。