如何解决RESOURCE_SEMAPHORE和RESOURCE_SEMAPHORE_QUERY_COMPILE等待类型

我们试图找出运行缓慢的sql服务器查询从以下配置之一托管的服务器（大小为300 GB）中命中/获取数据的根本原因：

Windows Server 2003 R2，SP2，企业版，16 GB RAM，12 CPU 32位

SQL Server 2005 SP4企业版32位。

我们已经通知企业升级到64位需要一个多月的时间。

但是对于当前问题，如果可以解决内存压力或最终得出结论以增加RAM，则我们正在尝试收集数据。

完成的操作：重新索引和更新统计信息适用于此数据库。

如下图所示，我们已经注意到过去5天在加载时间内运行的信号量等待类型：

以下查询后很少有信息：缓冲区大小= 137272

SELECT SUM(virtual_memory_committed_kb)
FROM sys.dm_os_memory_clerks
WHERE type='MEMORYCLERK_SQLBUFFERPOOL'

和以下每个查询的信号量内存= 644024

 SELECT SUM(total_memory_kb)
FROM sys.dm_exec_query_resource_semaphores

以下是从dm_exec_query_resource_semaphores和sys.dm_exec_query_memory_grantsdvv 收集的更多信息

因此，从上面收集的信息和每个SP_Blitz数据来看，资源信号似乎是问题所在。

与可用的16 GB RAM相比，是否为资源信号ID分配的内存'target_memory_kb'太低。

注意*运行8小时的每次分析“ target_memory_kb”始终小于1 GB，而可用的16 GB是多少？

这里可能是什么问题以及如何解决，请提出建议

谢谢

哦，天哪，我这里有个坏消息。

在32位操作系统上，SQL Server仅将前4GB的内存用于查询工作区之类的东西。（它也在为4GB的操作系统而战-其他正在运行的应用程序也将争夺该内存。）

4GB听起来可能很多，但是编写一个需要几个GB内存才能运行的查询相对容易。当足够多的查询需要足够的内存时，SQL Server会引发RESOURCE_SEMAPHORE等待，因为查询无法获得足够的内存来启动。RESOURCE_SEMAPHORE_QUERY_COMPILE意味着他们甚至没有足够的内存来编译执行计划-是的，这很糟糕。

那么如何解决呢？

• 切换到64位操作系统（无论如何，您正在运行的操作系统长期以来都不受支持）
• 切换到64位版本的SQL Server
• 减少服务器上的内存需求（不要在此盒子上运行任何其他应用，这在32位盒子上尤为重要，因为我们的上限为4GB）
• 通过AWE / PAE开关使用更多的内存-例外情况不适用于RESOURCE_SEMAPHORE等待，因为SQL Server只能将前4GB用于查询工作区
• 调整查询和索引，以便它们需要更少的内存

我什至不敢说最后一个，因为32位问题太糟糕了，在旧版本的SQL Server上确实很难。如果您使用的是当前版本，则可以遍历计划缓存并按内存授权对查询进行排序，找到最大的授权接受者，然后进行调整。不过，这件旧古董不是一个选择。