接下来,KB3170112引入了Showplan XML的新属性,即Server 2014或2016。
MaxQueryMemory in MemoryGrantInfo:如果查询需要内存才能运行,则单个查询授权的最大可用内存量(以KB计)。
属性GrantedMemory在公布之前就已经存在了。现在,两者都在Showplan XML中。
下面是一个示例:

从上面的图片中,如果我添加RequestedMemory和RequiredMemory的值,总计是=62,864 KB。MaxQueryMemory的295,344 KB值来自哪里?这个值到底意味着什么?
我还查看了2017年年计划,它的定义低于定义。
MaxQueryMemory:允许单次查询的最大内存( KB )。
发布于 2018-02-05 04:29:21
这是您可以从sys.dm_exec_查询_资源_信号量获得的相同信息的快照。我相信它是用于常规资源信号量的target_memory_kb乘以执行查询的资源调控器组的最大查询授权百分比。如果未启用RG,则只需使用默认的25%即可。
在我查看的服务器上,我通常看到大约28%的服务器内存无法用于查询内存授予。因此,一旦我运行了一个工作负载,可用于查询的最大查询授权是0.25 * 0.72 * MaxServerMemory。
下面是一个您可以运行的查询,该查询几乎立即完成,但要求获得大量内存授权:
DECLARE @zero INT = 0;
WITH CTE AS (
SELECT high
FROM master..spt_values
WHERE @zero = 1
)
SELECT *
FROM CTE t1
CROSS JOIN CTE t2
CROSS JOIN CTE t3
ORDER BY t1.high + t2.high + t3.high;如果强制该查询超时,则在实际计划中得到以下内容:

MaxQueryMemory不会因为超时而改变。它不会受到当前正在执行和使用查询内存的其他查询的直接影响。它间接受到任何更改资源池的目标内存KB的影响。
如果您有许多不同的资源管理器池和组,并且希望验证查询是否到达正确的位置,则此信息可能非常有用。它还可以为您无法访问的服务器的总体大小或配置提供上下文。这是另一种判断查询是否超时等待内存分配的方法,但是已经有其他方法可以做到这一点。预期的用例可能是提供更多关于目标内存在服务器上发生较大变化所导致的性能问题的信息,但我个人从未见过这样的情况发生。也许它可以发生在运行了多个Server实例的服务器上?
发布于 2018-02-01 06:53:10
我引用同样的支持文章更新以公开Server 2014或2016中Showplan XML中单个查询启用的最大内存
MaxQueryMemory in MemoryGrantInfo:如果查询需要内存才能运行,则单个查询授权的最大可用内存量(以KB计)。
这意味着在“当前”情况下,如果查询在处理过程中请求内存,则可以授予该查询的最大内存量。此值是在查询运行时计算的,该值考虑到其他正在运行的查询的内存需求以及所使用的系统内存。这对于解决运行缓慢的查询非常有用,因为统计数据是倾斜的,优化器准备次优计划,这会迫使查询请求与运行时实际需要的内存不同的内存。当它的请求比所要求的要高得多时,查询就会变得非常慢,因为它没有被授予所需的内存。这也有助于理解系统是否存在内存压力。
GrantedQueryMemory OTOH是指以千字节为单位的“实际”内存总量。如果尚未授予内存,则可以为空。MaxQueryMemory表示可以授予的最大值。
值得一读的博客。理解查询内存赠款
https://dba.stackexchange.com/questions/196785
复制相似问题