Forum Discussion
Advocate IICapacity Query Memory Limit % not working
We have set a query memory limit of 10% on our F256 SKU, as well as a query timeout:
Despite this, we are still seeing spikes of 15%+ on a model that is known to be problematic:
Does anyone know why this would happen? I'm wondering if the query timeout is taking precedence, and it's just ignoring the memory limit %, but not seeing any documentation on that. This is an import model that has historically had issues with slowness; we are rebuilding it so I'm not looking for tips on improving data models, just wondering how we can prevent these spikes in the interim.
4 Replies
Murtaza_GhafoorSuper User
Hi LeifB,
The key point here to understand that
The 10% Query Memory Limit does not mean the entire F256 capacity can never show more than 10% memory utilization.
The setting controls the maximum memory available to an individual DAX/MDX query for temporary/intermediate results, not a hard cap on the total memory that the semantic-model workload can consume.
Microsoft describes Query Memory Limit as the maximum percentage of available memory that can be used for executing an MDX/DAX query.
So if you see 15%+ capacity memory usage does not, by itself, demonstrate that the 10% limit was bypassed.
In your F256 example
An F256 has 100 GB maximum memory for semantic-model workloads, and the documented SKU maximum memory per query is 10 GB.
If you configure:
Query Memory Limit = 10%
you should think of that as a query-level resource-governance limit, rather than:
"This semantic model/report is allowed to consume only 10% of the F256's memory."
If this helps, ✓ Mark as Kudos | Help Other
LeifBI am not referring to the overall usage when I say "spikes of over 15%", in my second screenshot there are six individual queries that are showing as over the 10% limit. I'm wondering why those individual queries are allowed to exceed the threshold.
- GilbertQ
Hi LeifB
What you have to remember is that due to having a 10% query memory limit, there are still some other lying factors that need to be considered when a query is running because it is not only memory that is being utilized but also CPU which would factor into it showing the 15% spark due to those other factors of the model running, getting the data, etc.
- LeifB
Thanks, that makes sense. Do you know if there's a way to see the true % of memory being used? Or alternatively, approximately how much higher the percentage will go because of the "other factors"?
