Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Earn the coveted Fabric Analytics Engineer certification. 100% off your exam for a limited time only!

Reply
IanWaring
Helper IV
Helper IV

Small model suddenly throwing Resource Governing errors on PowerBI.com

I have a Power BI Desktop model that reads in around 9000 purchase requisitions (and same number of purchase headers) from D365FO. Then pulls 300 or so approved reqs from Dataverse approvals, each doing lookups on tables from 3 queries (1 built from ALL and 2 using SUMMARIZE; all around 9,000 rows each). Has been working fine for over 6 months, but this month all my users get this:

"Resource Governing: This query uses more memory than the configured limit. The query — or calculations referenced by it — might be too memory-intensive to run. Either reach out to your Analysis Services server administrator to increase the per-query memory limit or optimize the query so it consumes less memory. More details: consumed memory 1024 MB, memory limit 1024 MB."

I'm having difficulty seeing how I can simplify the DAX any more than I have already. It's already a fairly trivially small model.

Have the resources on PowerBI.com been more constrained than before? Or any ideas how I can assess which query is suddenly making the model hit it's head on the resource ceiling??

1 ACCEPTED SOLUTION
IanWaring
Helper IV
Helper IV

Involved Microsoft Premier Support and discovered the root cause - which wasn't what we thought it was. The business problem was that I had requisition approvals in Power Automate flows, but had a need to bring in data from both the source D365FO purchase requisitions and corresponding purchase orders; in addition, some data from vendors and employees to populate some of my view. As reqs are created throughout the day, I needed latest data - which I sourced from entities downloaded via ODATA connections.

I set the model to update on PowerBI.com every hour or so, so independent of the time it took to fish the data for the latest view, the current status on all reqs would be there whenever users dipped in to have a look.

There appears to have been a change in PowerBI.com where if a view takes longer than 225 seconds to source all its data, it will point blank refuse to show the view, citing that "lack of resources" error message - even if you pull up the display what was refreshed some time back.

Temporary fix is to add a slicer and set it with a start date just beyond the minimum date in the data set (in my case by 4 weeks in 18 months of data), then the visual will render. The long term fix is to shift the data sourcing to be via Azure Data Lake, so the query is several orders of magnitude faster than we can achieve with synchronous ODATA connections.

View solution in original post

2 REPLIES 2
IanWaring
Helper IV
Helper IV

Involved Microsoft Premier Support and discovered the root cause - which wasn't what we thought it was. The business problem was that I had requisition approvals in Power Automate flows, but had a need to bring in data from both the source D365FO purchase requisitions and corresponding purchase orders; in addition, some data from vendors and employees to populate some of my view. As reqs are created throughout the day, I needed latest data - which I sourced from entities downloaded via ODATA connections.

I set the model to update on PowerBI.com every hour or so, so independent of the time it took to fish the data for the latest view, the current status on all reqs would be there whenever users dipped in to have a look.

There appears to have been a change in PowerBI.com where if a view takes longer than 225 seconds to source all its data, it will point blank refuse to show the view, citing that "lack of resources" error message - even if you pull up the display what was refreshed some time back.

Temporary fix is to add a slicer and set it with a start date just beyond the minimum date in the data set (in my case by 4 weeks in 18 months of data), then the visual will render. The long term fix is to shift the data sourcing to be via Azure Data Lake, so the query is several orders of magnitude faster than we can achieve with synchronous ODATA connections.

GilbertQ
Super User
Super User

Hi @IanWaring 

 

It could well happen if your columns are text columns and each of them is unique this could consume a large amount of memory as indicated in the error.





Did I answer your question? Mark my post as a solution!

Proud to be a Super User!







Power BI Blog

Helpful resources

Announcements
April AMA free

Microsoft Fabric AMA Livestream

Join us Tuesday, April 09, 9:00 – 10:00 AM PST for a live, expert-led Q&A session on all things Microsoft Fabric!

March Fabric Community Update

Fabric Community Update - March 2024

Find out what's new and trending in the Fabric Community.

Top Solution Authors
Top Kudoed Authors