Configuring Query Memory Limit (%) on F256 Capacity

[Doragotak]

Hi everybody!
I should set a Query Memory Limit (%) on an F256 capacity. Currently, it is at the default value, which I believe is equivalent to 10GB. As I understand it, this is a soft limit. If I set a specific value manually, it will become a hard limit, which means in case of exceeding the capacity, this would ensure that throttling doesn't affect everyone; instead, the report would only stop working for the user who exceeded the limit (would receive an error message). What Query Memory Limit (%) would correspond to this 10GB default value?
Any insights would be appreciated!

[ibarrau · Accepted solution]

Hi. I don't think that query memory limit is what you are looking for. Your comment sounds like you would like to protect the user experience and prevent the backend operations to take it all if something goes wrong.

If that's right what you need is surge protection. You can limit the background. You can configure and say the back won't use more than X % of the capacity. Its 100% will be the X %. That way you keep an interactivity layer to protect the experience. How to know how much? well check the capacity interativity and check how users are using to have an idea.

You can read more googling or here: https://blog.ladataweb.com.ar/post/775835160112398336/fabric-protegé-la-experiencia-de-usuarios-en-u...

I hope that helps

[lbendlin]

To extend on @ibarrau 's answer - We found Surge protection to be rather pointless as it restricts ALL background operations.  Not just refreshes, but also cross-semantic model queries an all Copilot activities and lots of other artifacts that you wouldn't normally classify as background.  It is also based on the background rejection threshold (which is very well hidden), not the background activity level.

There's a new workspace level setting that can block an entire workspace - including interactive artifacts !!!  Not sure who thought that would be a good idea.