如何解决 SQL 2012 中如何限制资源管理查询的问题？

Question

我在 SQL 2012 SP1 (ent) 上有一个并行查询，它在用户定义的资源调控器池中运行的速度比在用户定义的池中运行的慢得多（2 秒与 125 到 140 秒在用户定义的池中 = ~ 75 倍慢）比在其中运行的相同查询默认资源池。

两次执行之间的查询计划哈希是相同的，并且统计 io 为所有操作返回相同的值。我已经确认执行计划没有额外的溢出警告（两者都有一个），并且查询的内存授予是相同的。

用户定义的池工作负载组

<QueryPlan DegreeOfParallelism="4" MemoryGrant="2384096" CachedPlanSize="384" CompileTime="3608" CompileCPU="2712" CompileMemory="15672">
        <ThreadStat Branches="5" UsedThreads="20">
          <ThreadReservation NodeId="0" ReservedThreads="20" />
        </ThreadStat>
        <MemoryGrantInfo SerialRequiredMemory="5632" SerialDesiredMemory="2360768" RequiredMemory="28960" DesiredMemory="2384096" RequestedMemory="2384096" GrantWaitTime="0" GrantedMemory="2384096" MaxUsedMemory="93872" />
        <OptimizerHardwareDependentProperties EstimatedAvailableMemoryGrant="209715" EstimatedPagesCached="104857" EstimatedAvailableDegreeOfParallelism="4" />

默认池

<QueryPlan DegreeOfParallelism="4" MemoryGrant="2384096" CachedPlanSize="384" CompileTime="3016" CompileCPU="2660" CompileMemory="15672">
            <ThreadStat Branches="5" UsedThreads="20">
              <ThreadReservation NodeId="0" ReservedThreads="20" />
            </ThreadStat>
            <MemoryGrantInfo SerialRequiredMemory="5632" SerialDesiredMemory="2360768" RequiredMemory="28960" DesiredMemory="2384096" RequestedMemory="2384096" GrantWaitTime="0" GrantedMemory="2384096" MaxUsedMemory="88768" />
            <OptimizerHardwareDependentProperties EstimatedAvailableMemoryGrant="209715" EstimatedPagesCached="104857" EstimatedAvailableDegreeOfParallelism="4" />

查询之间的 Total_worker_time 几乎相同。唯一看起来不同的是 total_elapsed_time。等待是 cxpacket。在这一点上，我必须认为这是资源调控器为限制 CPU 和/或内存所做的事情。虽然我找不到任何节流的证据。CPU 节流计数器不会移动，内存次优计划/秒也不会移动。

对于工作负载组，我使用了超过默认值 (25%) 的内存授权，并使用了最大 dop 设置。除非我让查询串行执行，否则对执行时间没有任何影响。如果我将工作负载组的 maxdop 更改为 1（串行执行），查询会在大约 3 秒内在缓存中运行一次（比默认组慢 1 秒）。所有其他级别的 maxdop 导致 ~70 和 75 倍慢）。

服务器信息：2 插槽 x 6 核心服务器。服务器 MaxDop = 4。当我执行测试时，CPU 相对处于静止状态（~12% 的利用率）。服务器上的内存没有压力（在 24GB 的盒子上大约有 6GB 可用空间）。

资源池配置

100% 最大内存

50% CPU（增加到 100% 没有任何区别）

75% CPU CAP

工作负载组

MaxDop 0（并尝试过 0、1、4、7）

内存授予（25% - 并尝试过 SQL 建议的最大值为 70%）

关于如何缩小限制范围的任何想法？我没有从 Microsoft 链接中看到任何明显的故障排除信息

http://technet.microsoft.com/en-us/library/cc627395(v=sql.105).aspx

默认池（快速）执行的完整计划 - http://pastebin.com/y0P9J61f

用户池（慢）执行的完整计划 - http://pastebin.com/20hnFSTW

问题查询是计划中的第二个语句（第一个无关紧要，无论如何都不会并行运行......）

Answer 1

更新 - 我仍然不知道如何最好地检测发生了什么类型的节流，但我确实找到了我的情况的罪魁祸首。CPU CAP 降低至 75% 所导致的性能下降幅度似乎确实比 25% 下降幅度所表明的要严重得多。将 CPU 上限提高到 100% 解决了该问题。

一篇连接文章似乎证实这可能是 CPU Cap 实现本身的问题。

这不是这个问题的最佳答案，如果有人仍然想回答原来的“如何判断正在发生什么节流......”问题。我会很乐意的。

如果您很难理解为什么查询受到如此严重的限制，这可能是一个值得尝试的解决方案。

http://connect.microsoft.com/SQLServer/feedback/details/781335/resource-governor-feature-cap-cpu-percent-does-not-work-as-expected