资源调控器故障排除

如果没有可用来进行分类的分类器 UDF，则所有会话都将自动分类到默认工作负荷组。创建分类器 UDF 后，您需要验证是否向资源调控器注册了它以及是否更新了内存中的配置。

创建、注册和启用分类器 UDF 的过程包括三步：

• 首先，需要创建此函数。

  CREATE FUNCTION function_name() RETURNS <something> 
  WITH SCHEMABINDING
  

• 其次，需要向资源调控器注册此函数。

  ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION=schema_name.function_name)
  

• 再次，需要更新资源调控器在内存中的配置。

  ALTER RESOURCE GOVERNOR RECONFIGURE
  

排除分类方面的故障时首先应做的事情就是验证是否向资源调控器注册了您创建的函数以及是否更新了相应配置。使用下面的查询可获得资源调控器当前正在使用的分类器 UDF 的架构名称 (schema_name) 和分类器函数名称 (function_name)。

USE master
SELECT 
      object_schema_name(classifier_function_id) AS [schema_name],
      object_name(classifier_function_id) AS [function_name]
FROM sys.dm_resource_governor_configuration

您更改了分类器 UDF，但资源调控器仍在使用以前的函数逻辑来对会话进行分类，在这种情况下您可以使用前述方法进行故障排除。此行为表示您所做的更改未应用于内存中的配置。

您可能会创建不产生预期结果或占用大量资源的非常复杂的分类器函数。如果您已经进行了基本故障排除，那么您就需要验证函数逻辑是否合理。最糟糕的情形是，因存在代码编写方面的缺陷而造成无限循环或失控查询。

可以使用专用管理员连接 (DAC) 来排除编写拙劣的分类器函数的故障，因为 DAC 不进行分类，可以在资源调控器运行并对传入会话进行分类时使用。有关详细信息，请参阅使用专用管理员连接。

注意
如果没有 DAC 可用来进行故障排除，则可以在单用户模式下重新启动系统。虽然单用户模式不进行分类，但您无法在资源调控器分类运行时对它进行诊断。

可通过查询以下内容获得有关分类器函数的信息：

• sys.dm_exec_query_stats（包含语句信息，但不包含实际函数）

• sys.dm_exec_sql_text（与从 sys.dm_exec_query_stats 获得的 sql_handle 一起使用）

• PreConnect:Starting 事件类（提供分类器函数的 ID 和名称）

在这种情况下，用户报告性能出现下降，您怀疑请求计数受到限制。

您首先需要验证是否显式为此用户所属的组配置了请求计数限制，方法是：检查此用户的组成员资格，以查看是否启用了 GROUP_MAX_REQUESTS 设置。如果未启用 GROUP_MAX_REQUESTS，则不存在显式请求计数限制。您应通过采取以下步骤做进一步调查。

• 查询 sys.dm_os_waiting_tasks，以查看 RESMGR_THROTTLED 等待类型中是否有任何正在等待的请求。存在这种等待类型表明存在请求计数限制。

• 启动性能监视器，然后使用 Queued requests 和 Active requests 计数器收集数据。如果 Queued request 计数不为零，则表明存在请求限制。

• 检查 Active requests 值是否与 GROUP_MAX_REQUESTS 设置匹配。如果 Active requests 值高于 GROUP_MAX_REQUESTS 设置，则组可能会有无法限制的请求（如打开的事务）。

• 如果 Queued requests 为零，请检查共享同一资源池的所有工作负荷组的 Active requests，因为该池可能已因为请求数过多而超载。

如果您有受资源调控器事件生成驱动的策略，则在达到最大 CPU 限制时您可以使用生成的事件。

在这种情况下，您需要确定您为检测占用过多 CPU 资源的查询而配置的最大 CPU 限制 (REQUEST_MAX_CPU_TIME_SEC) 是否过低。

以下操作将有助于您验证 CPU 限制设置。

• 启动 SQL 跟踪会话，然后收集 CPU Threshold Exceeded 事件。当用户请求达到最大 CPU 使用限制时，服务器会自动生成一个 SQL 跟踪事件。如果您的设置过低，将会生成大量这种事件。

注意
该事件还会显示为一个服务器事件通知，所以您可以编写对该事件做出响应的脚本。

• 启动性能监视器，然后使用 Max request cpu time (ms) 计数器收集数据。您可以参照此计数器的值来为工作负荷组设置适当的限制。

在这种情况下，您怀疑 CPU 带宽受到限制，原因是 CPU usage % 性能计数器达到或接近资源调控器的 MAX_CPU_PERCENT 设置值。下面的查询返回一个 SQL Server 实例的所有工作负荷组和资源池的 CPU 使用百分比值。

select * from sys.dm_os_performance_counters where counter_name = 'cpu usage %'

有关详细信息，请参阅 sys.dm_os_performance_counters (Transact-SQL)。

您可以通过对系统执行以下检查来确定 CPU 带宽是否受到限制。

• 检查服务器 CPU 的总使用率。如果有 SQL Server 以外的负载当前处于活动状态，它可能会影响您正在进行故障排除的查询。

• 检查各个资源池的 CPU 使用率分布。资源池可能会因为其他池的 CPU 最低使用率配置值较高而受到限制。将计数器的预期值（计算得出的 CPU 使用率）与实际 CPU 使用率进行比较。

• 检查分配给相关资源池的工作负荷组。其他工作负荷组带来的负载可能会影响共享同一池的用户。

• 检查各个计划程序的 CPU 使用率分布。您所调查的查询可能针对的是包含长时间运行的查询的计划程序。在这种情况下，此查询可能看起来受到限制，但实际问题在于各个计划程序之间负载分布不均。

• 检查是否可能存在这样的情况：工作负荷受到其他会话的阻碍，而不是受到资源调控器设置的限制。

• 检查系统中当前正在运行查询的会话数目。随着并发执行的请求数目的增长，SQL Server 将试图确保所有这些请求都至少收到一定量的 CPU 时间以防出现 CPU 匮乏。

在这种情况下，您怀疑所授予内存的大小是导致查询运行缓慢的原因。

资源调控器通过减少所授予的内存量来强制实施最大查询内存限制，以便大型查询不超出此限制。如果查询获得的内存授予不足 100%，可能有必要溢出临时数据并将其写入磁盘，这样做对性能的提升有明显的效果。

您需要确定大型查询所占的百分比，以便设置适当的最大查询大小限制。以下操作将有助于确定最佳设置：

• 查询 sys.dm_exec_query_memory_grants 以查看当前内存授予状态。ideal_memory_kb 列显示了根据基数估计确定的理想量。requested_memory_kb 列显示了请求的量，在达到最大查询限制后，此量可能会降低。如果 requested_memory_kb 大大低于 ideal_memory_kb，则查询最终可能会频繁溢出（假定基数估计正确）。

• 启动性能监视器，然后使用 Reduced memory grants/sec 计数器收集数据。此计数器的值表示在达到最大请求大小限制后收到的量低于理想量的内存授予计数的比率。大型查询在运行速度方面可能会远远慢于具有理想量的那些查询，因为它们需要溢出到磁盘才能不超出内存限制。

若要缓解内存授予问题，您可能需要增加池大小限制值或最大内存大小限制值。

注意
如果您只增加最大内存大小，可能会导致可并发运行的大型查询数减少。

在这种情况下，查询因出现内存授予超时错误而失败。

但在工作负荷组和资源池定义中指定的活动内存授予请求总数和内存限制可能会在内存授予超时方面起到一定的作用。如果单个资源池由多个资源组共享，则其他组中的并发查询数目也可能影响内存授予超时。

以下操作将有助于确定最佳资源池设置：

• 查询 sys.dm_exec_query_memory_grants 以查看此组及池的内存授予数和正在等待的查询数。

• 查询 sys.dm_exec_query_resource_semaphores 以查看总的内存授予量和目标数。

如果授予使用的内存量大于可用内存空间，则您可以考虑增加资源池大小限制值。

查询因出现内存不足错误而失败。

基本故障排除

高级故障排除

内存不足 (701) 错误属于一般性错误，在以下情况下返回：任务尝试从内存管理器中分配内存块，但这种尝试失败。有关详细信息，请参阅 MSSQLSERVER_701。

以下情况可能会引发此错误：

• 内存池达到其总量限制。

注意
这种情况可能并非完全由资源调控器造成的。服务器上可能有其他一些正在运行的应用程序，它们的内存需要促成了这种情况。

• 多页或虚拟地址空间分配失败，原因是虚拟地址空间没有足够大的可用块来容纳所需保留项。这很有可能发生在 32 位体系结构上，不太可能发生在 64 位体系结构上。

• 多页或虚拟地址空间分配失败，原因是总提交量达到提交限制。32 位和 64 位体系结构上都有可能发生此问题。

当您看到内存不足错误时，最好从错误日志着手调查此错误。日志包含与下例类似的输出：

2006-01-28 04:27:15.43 spid51 Failed allocate pages: FAIL_PAGE_ALLOCATION 1

错误日志中可能记录的失败有：

• FAIL_PAGE_ALLOCATION，后面跟着尝试分配的页数

• FAIL_VIRTUAL_RESERVE，后面跟着尝试保留的字节数

• FAIL_VIRTUAL_COMMIT，后面跟着尝试提交的字节数

请务必了解，触发内存不足错误的任务往往不是引发此错误的任务。除非有失控任务，否则内存不足情况通常是多个正在运行的任务共同促成的最终结果。因此，在遇到十分常见的 FAIL_PAGE_ALLOCATION 错误时，必须调查更大范围的系统活动。

错误日志中另一项有用的信息是内存状态输出。根据失败的不同，您应该查找各个内存 Clerk 的单页数值、多页数值、保留的虚拟内存数值或已提交的数值。识别最大的内存占用者是继续调查此错误的一个关键步骤。通常，最大的内存占用者属于以下类型：

• MEMORYCLERK_* 表示服务器配置或工作负荷需要分配特定量的内存。SQL Server 组件有对应的内存 Clerk，并且单个组件可以有多个内存 Clerk。有关详细信息，请参阅 sys.dm_os_memory_clerks。有时您可以根据内存 Clerk 识别造成问题的工作负荷，但您更有可能需要通过检查与 Clerk 关联的内存对象来找出占用大量内存的原因。

• CACHESTORE_*、USERSTORE_*、OBJECTSTORE_* 是缓存的类型。缓存占用较多内存可能意味着：

  • 内存已从缓存中分配出来，但尚未作为可以逐出的项插入。这与上面的 MEMORYCLERK 情况非常相似。

  • 所有的缓存项都正在使用，所以无法将它们逐出。可通过查看 sys.dm_os_memory_cache_counters 并比较 entries_count 列和 entries_in_use_count 列的值来确认这一点。

• MEMORYCLERK_SQLQERESERVATIONS 显示了查询执行 (QE) 保留用于运行带排序/联接的查询的内存量。在保留的量很高时发生的内存不足错误通常表示服务器中存在 Bug。

错误日志中的内存状态输出还将显示已用尽的内存池。每个池的内存中介器显示了盗用的（编译）内存、缓存的内存和保留的（授予的）内存之间的内存分布。三个中介器的编号对应于前面与内存 Clerk 关联的内存对象。您可以根据给定的 Clerk 或内存对象查出为一个池分配的内存量，方法是使用自定义脚本从完整转储提取信息；此外，sys.dm_os_memory_cache_entries 动态管理视图显示了与每一项关联的 pool_id。

如果需要与客户支持服务部门联系，请为我们的支持人员收集以下信息：

• 显示内存不足错误以及出现此错误时的内存状态输出的错误日志。

• 执行以下语句所得到的输出：

  dbcc memorystatus
  dbcc sqlperf(spinlockstats)
  select * from sys.dm_os_memory_clerks
  select * from sys.dm_os_wait_stats order by wait_type
  select * from sys.dm_os_waiting_tasks
  select * from sys.dm_os_ring_buffers where ring_buffer_type='RING_BUFFER_OOM'
  select * from sys.dm_os_ring_buffers where ring_buffer_type='RING_BUFFER_RESOURCE_MONITOR'
  select * from sys.dm_os_ring_buffers where ring_buffer_type='RING_BUFFER_MEMORY_BROKER'
  select * from sys.dm_os_memory_cache_clock_hands
  

• 使用 T8004 收集的内存不足转储（可选）。此小型转储将包含一些有用的信息，如环形缓冲区和自旋锁/等待统计信息。通过关闭 T8004，再重新打开它，无需重新启动服务器，即可重置 T8004 的转储计数器。

在这种情况下，您怀疑查询运行缓慢的原因是查询计划不是最优的。如果查询优化器因为资源池的内存限制设置较低而没有获得足够的内存，则它可能生成非最优查询计划。

以下操作将有助于确定最佳资源池设置：

• 从 Query optimizations/sec 计数器获得数据以查看工作负荷组是否有大量查询编译。

• 从 Suboptimal plans/sec 计数器获得数据以查看查询优化器是否频繁生成非最优计划。

如果存在上述任意一种情况，请考虑增大资源池的内存限制值。