问SQL Server 2016的奇怪内存压力

EN

Jonathan在标题为SQLSkills.com的SQL Wow…一个在线计算器错误配置您的服务器内存！上有一篇很酷的文章。

乔纳森在他的文章中写道：

我的一般建议是使用我的书“服务器故障排除:意外DBA指南”中的计算，它将为操作系统保留1GB内存，为从4-16 GB安装的每4GB RAM保留1GB，然后为安装在16 GB之上的每8GB RAM保留1GB。这并不是一个过于技术性的计算，但它工作得很好，通常会配置“最大服务器内存”，使服务器稳定并具有可靠的性能。

如果您继续使用这个示例，那么您最好将Server配置为以81 GB的max_memory设置运行。

您可以创建一个Excel，使用以下公式和数据生成一个很好的SQL Server Max内存设置图。

Excel表以HW内存(A2)列开头：

4

保留的第二列OS (B2)的Excel公式是：

IF(A2<=16;1 + A2/4;1+4+(A2-16)/8)

然后，列(C2)如下：

A1-A2

这将产生以下图表：

可能的解决方案

如您所见，如果您有96 GB的内存，那么您应该为操作系统预留15 GB的内存，并将SQL内存(max_memory)设置为81 GB。

乔纳森在他的文章中解释说..。

server具有SQLOS的内置组件资源监视器( Resource )，该组件监视QueryMemoryResourceNotification Windows以获取服务器上OS级内存可用性的状态。如果Windows OS处于内存压力之下，它将设置一个低内存通知，即资源监视器线程将检测并强制缓存上的外部时钟手在内部开始清除缓存，并减少内存使用，从而允许进程将内存释放回操作系统。

您的操作系统可能没有足够的内存，正在将内存从Server操作系统中删除。

将max_memory设置稍微减少到81 GB将允许操作系统和其他未在max_memory设置中运行的Server组件拥有足够的内存。

你的里程可能会不同

我可能弄错了，但我们还是试试吧。也许这会对你有帮助。

从截图中可以看出，当你开始出现性能问题时，页面的预期寿命就会出现问题。我想您看到的查询有很长的PAGEIOLATCH_*等待时间吗？您还提到正在生成不良计划，运行临时解决了问题。对我来说，这听起来像是典型的参数嗅探症状。我猜您有一个查询，当使用错误的参数编译时，它会进行表扫描而不是查找，使用错误的索引或查询计划的形状更改。一般来说，这是一个需要大量I/O和饱和存储子系统的查询，所以即使是简单的查询，做键查找也会变得缓慢。当您有性能问题时，我会尝试确定哪一个是它，并通过删除它的计划来确认。

要确定有问题的查询，我只需要查看那些有长PAGEIOLATCH等待的查询，并比较它们的快速执行计划。

要想解决这个问题，你必须要有创造力。您可以尝试添加查询提示，强制每次执行时重新编译，使用计划指南。我还成功地更改了底层表上的索引，并重写了有问题的查询。很难提出任何具体的建议，因为你现在的问题是找出是什么导致了你的问题。

在夜间运行SSIS作业时，我看到了类似的问题，有时Sentryone由于任何原因都看不到SSIS内存的使用。我想看看S1中的事件日历，看看当时哪些作业在运行。