Forum Discussion
Microsoft EmployeeMemory limit issue for Direct Lake reports
Hi,
We're experiencing persistent memory-related errors with our Direct Lake semantic model despite upgrading our Fabric capacity and optimizing model.
Environment:
- Current Capacity: F256 SKU (upgraded from F128)
- Setup: Direct Lake semantic model with ~10 live-connected Power BI reports
- Error Type: QueryUserError - Memory allocation exceeded
- Previously (F128 SKU): No memory issues, system running fine
- Last week: Started encountering memory errors with the same workload
- Recent action: Upgraded to F256 SKU (100 GB capacity)
Current Status:
After upgrading to F256, we've seen partial improvement:
- The maximum 50 GB memory errors have stopped
- Still receiving "maximum allowable memory allocation for your tier" errors
- We have implemented a notebook-based solution to pre-warm semantic model, which has successfully reduced page load times for our reports. However, from this week it is also not resolving any error related to the memory allocation.
When Do These Errors Occur?
We're encountering two distinct error patterns (screenshots attached on top):
Error Type 1 (Before F256 upgrade): "Resource Governance: consumed memory 80495 MB, memory limit 51200 MB" - This is resolved after Fabric upgrade.
Error Type 2 (Current - After F256 upgrade): "You have reached the maximum allowable memory allocation for your tier"
Questions:
- Why would memory errors suddenly appear after weeks of stable operation on F128?
- Is there a recommended approach to diagnose which reports/queries are consuming excessive memory?
- Should we consider further capacity upgrade or are there alternative solutions?
Any guidance would be greatly appreciated!
Hi v-mahisingh,
Hope you are doing well!
Your two errors are different problems, you've correctly solved Error 1. Error 2 is a per-query memory limit, not a total capacity issue, so upgrading SKU again won't fix it.
Why errors appeared suddenly: Your Delta tables silently accumulated fragmentation and data growth over weeks. Processing data near real-time can cause a proliferation of small Parquet files and row groups, which negatively affects Direct Lake performance. (Microsoft Learn) Once fragmentation crosses a threshold, transcoding cost per query spikes, that's the "sudden" behaviour.
Why pre-warm stopped helping: Pre-warming loads columns into memory, but if column segments are now larger/more fragmented, the per-query memory cost is too high regardless.
Here's an order of priorities:
1. Run OPTIMIZE + V-Order immediately on all Gold tables feeding your model, V-Order delivers 40–60% improvement on cold-cache queries for Direct Lake (Christopher Finlan).
2. Schedule regular maintenance (weekly minimum, daily if you have frequent writes).
3. Remove unused columns from the semantic model, every unused column pulled in by a measure wastes per-query memory.
4. Review expensive DAX measures using DAX Studio Server Timings, high Storage Engine scan counts = high memory per query.
5. Do not upgrade to F512, the memory limit covers not just the model in memory, but refresh behaviour, query execution, and internal overhead (Tabulareditor), fixing the data layer is the correct path.
To sum up : with 10 live-connected reports hitting the model concurrently, the combination of data growth and Delta table fragmentation is driving up transcoding cost per query, this is the root cause of the sudden memory errors after a previously stable period. The pre-warm notebook has stopped helping for the same reason: it loads columns into memory, but the per-query memory cost is now too high regardless of warm state. The "maximum allowable memory for your tier" error is a per-query enforcement, not a total model cap, which is why upgrading to F512 would not solve it, the fix belongs at the data and model layer, not the capacity layer. The immediate actions are to run OPTIMIZE with V-Order on all Gold tables, establish a regular maintenance schedule, remove unused columns from the semantic model, and audit expensive DAX measures using DAX Studio Server Timings. If concurrent report pressure remains high after those steps, consider splitting reports across a second semantic model or staggering heavy query windows.
Hope this helps 🙂
5 Replies
- oussamahaimoud
Memorable Member
Hi v-mahisingh,
Hope you are doing well!
Your two errors are different problems, you've correctly solved Error 1. Error 2 is a per-query memory limit, not a total capacity issue, so upgrading SKU again won't fix it.
Why errors appeared suddenly: Your Delta tables silently accumulated fragmentation and data growth over weeks. Processing data near real-time can cause a proliferation of small Parquet files and row groups, which negatively affects Direct Lake performance. (Microsoft Learn) Once fragmentation crosses a threshold, transcoding cost per query spikes, that's the "sudden" behaviour.
Why pre-warm stopped helping: Pre-warming loads columns into memory, but if column segments are now larger/more fragmented, the per-query memory cost is too high regardless.
Here's an order of priorities:
1. Run OPTIMIZE + V-Order immediately on all Gold tables feeding your model, V-Order delivers 40–60% improvement on cold-cache queries for Direct Lake (Christopher Finlan).
2. Schedule regular maintenance (weekly minimum, daily if you have frequent writes).
3. Remove unused columns from the semantic model, every unused column pulled in by a measure wastes per-query memory.
4. Review expensive DAX measures using DAX Studio Server Timings, high Storage Engine scan counts = high memory per query.
5. Do not upgrade to F512, the memory limit covers not just the model in memory, but refresh behaviour, query execution, and internal overhead (Tabulareditor), fixing the data layer is the correct path.
To sum up : with 10 live-connected reports hitting the model concurrently, the combination of data growth and Delta table fragmentation is driving up transcoding cost per query, this is the root cause of the sudden memory errors after a previously stable period. The pre-warm notebook has stopped helping for the same reason: it loads columns into memory, but the per-query memory cost is now too high regardless of warm state. The "maximum allowable memory for your tier" error is a per-query enforcement, not a total model cap, which is why upgrading to F512 would not solve it, the fix belongs at the data and model layer, not the capacity layer. The immediate actions are to run OPTIMIZE with V-Order on all Gold tables, establish a regular maintenance schedule, remove unused columns from the semantic model, and audit expensive DAX measures using DAX Studio Server Timings. If concurrent report pressure remains high after those steps, consider splitting reports across a second semantic model or staggering heavy query windows.
Hope this helps 🙂
- HI v-mahisingh ,
I would like to thank oussamahaimoud for the detailed explanation and guidance provided on this issue. The breakdown around per-query memory limits and Delta table optimization is very helpful.
This aligns with Microsoft Fabric documentation, as Direct Lake loads required columns into memory during query execution, and only the data needed for a query is brought into memory.
Additionally, Microsoft guidance highlights that Direct Lake performance depends on well‑optimized Delta tables, including proper file layout and optimizations such as V‑Order, which improve query efficiency and performance.
Could you please review the solution and confirm if it helps resolve the issue from your end.
Thank you.Hi v-mahisingh ,
I hope the above details help you fix the issue. If you still have any questions or need more help, feel free to reach out. We’re always here to support you
Hi v-mahisingh ,
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.
- tayloramy
Super User
Hi v-mahisingh,
How much data are you talking about? A model consuming 80GB of memory leads me to believe that it is either not optimized, or that it has billion of rows which isn't ideal for a semantic model.
What I would recommend is to take a look and see if you can pre-aggregate rows in your fact table, or split the model up into smaller models for the different reports.
