问我可以采取哪些步骤来确定我的服务器是否没有为内存做好准备？

EN

下面是几个perfmon计数器，您可以使用它作为启动器。

内存奖励挂起--这是一个计数器，它告诉您是否有任何查询等待内存分配(内存分配)。这个应该是0。如果不止这些，你就有问题了。

页面预期寿命--这是页面在内存中停留的估计时间(以秒为单位)。越高越好，但是有一个公式可以计算出您的serer的最小值应该是什么。它曾经是300秒的最小值，但这是一个旧的计算，现在应该是每GB 100秒。我是在周六的SQL会议上从理查德·道格拉斯那里得到这个的，所以我要归功于他。他为SentryOne工作。小于此值的值告诉您分配的内存太少。还可以将此计数器与检查点页/秒结合使用。请注意，每个NUMA节点都有自己的PLE值(如果您在Server上有多个NUMA节点)。Server开始将资源划分到分配给8个核以上的(软) NUMA节点。

懒写/秒-当SQL Server遇到内存压力时，惰性写入程序会清除缓存中的旧页。经常超过20是一个问题(这也是从理查德道格拉斯那里得到的)。但是，将它与页面预期寿命结合使用。如果您看到较高的PLE以及延迟写入/秒的峰值，则会导致SQL从其缓存中删除页面并插入新页。请看下面的截图，看看我家实验室的一个例子。

我确信，这里的一些专家对记忆员了解得更多了，他们还在我的名单上更深入地研究，所以也许有人会为你提供一些额外的信息(我也非常感兴趣:-)。

编辑:如果你愿意的话，你也可以使用sys.dm_os_performance_counters动态查询来获取它们。

2020年6月24日编辑：

@J.D.关于你6月23日的评论，我也深入到记忆压力中，因为@Dominique的评论和本文：https://www.brentozar.com/archive/2020/06/page-life-expectancy-doesnt-mean-jack-and-you-should-stop-looking-at-it/。当我把这个放在邮箱里的时候，我笑了，也许他看到了这篇文章。-)这篇文章告诉我们不要再看它了。嗯，虽然布伦特肯定比我有更多的经验，但我认为我不能完全同意他的说法，不去看它。我在他的sp_BlitzFirst上下文中理解了他的观点，一个使用最多25%缓冲区缓存的查询，它是一个滞后指标等等，但是对于趋势分析和历史，我仍然会看到PLE。如果我想确定服务器是否随着时间的推移有内存压力，这就是我将使用的结合等待内存授予。另外，来自RedGate和Quest的监控工具仍然使用这种方法。现在@Dominique说要查看RESOURCE_SEMAPHORE等待，我同意这一点，但这很可能与挂起的内存授权(您可以很容易地在perfmon注册)的数量一致。如果您有一个常量的内存授权队列(它与FIFO队列一起工作)，那么您确实有内存压力。

作为参考，这是这个宇宙中某个系统(32 GB mem，1TB数据库，尽管工作负载类型也非常重要)的Lazy。黄色是批请求p/s，10表示一个1000，所以你可以看到它绝对不是空闲的。

这里还有我的家庭实验室提供的关于内存授权与RESOUCE_SEMPAPHORE等待的快照(我还看到我突出显示了tempdb写的内容，这就是david所说的，太少mem，所以请将内容转移到tempdb)：

现在，看看您的perfmon计数器，我认为您肯定会有内存问题。我的意思是，有些东西不断迫使Server从缓冲区缓存中删除页面。如果这是一次的话，好吧，但是似乎一直在忙着这样做.然而，我希望看到它们与PLE相比较。这可能是一个明确的迹象，有内存压力(随着时间的推移，我仍然这样认为)。其次，您还需要查看挂起的内存授权。我以前没这么说过，但回头看，我认为你想看看布伦特和多米尼克所说的等待数据。然而，随着时间的推移，这就有点困难了。等待状态是累积累积的，所以您需要先清除它们(我不喜欢)，然后查看它们是否是RESOURCE_SEMAPHORE加起来的。

若要清除等待状态：https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-sqlperf-transact-sql?view=sql-server-ver15

您也可以使用sp_BlitzFirst来监视它，但这只是运行它的时间点的快照。sp_BlitzFirst (或我想不起来的sp_Blitz )有一个选项，可以定期将其记录在表中，因此您也可以查看它。或者只是以其他方式查询dm_os_wait_stats也是有效的。总的来说，我个人的偏好是收集数据来分析这个问题。我使用Stedman: databasehealth.com的数据库健康监视器来完成这个任务。我家里实验室的截图：

这样，您可以更好地监视等待状态，尽管这将花费少量的资源。

如果您有Server 2017或更高版本(我们在env.中还没有这一点)，那么您也可以使用Query。截至Server 2017，Query还记录等待状态(这是一个可配置的选项)。不过，请小心，我已经阅读了Query将非常繁忙的服务器拖垮的故事(您可以使用wait stats :-P来监视这一点)。当然，在实现功能之前，您应该始终进行测试。我们确实使用了它，并且工作得很好，但是我们有2016年，所以我们确实错过了等待统计选项:-( )

顺便提一下，我的策略是收集信息(如果可能的话，请等待统计)，如果您认为内存压力很大，可以升级RAM (如果VM非常容易的话)，然后收集性能指标并检查它们是否有改进。有点没有头脑，但后者往往被遗忘或做得不好。