Forum Discussion
Impactful Individualmemory error doesnt seem right
hi we have fabric f4 capacity. Not that its perfect but we went to refresh an sm today that we havent looked at in a while and got the error you see below. Looking at cu's and storage in the fabric usage dashboard, im not seeing anything that stands out as the culprit. i'll post those images in replies.
10 Replies
db042190we got this email prior and im posting it here as i suspect it is related. But as shown in the images below that, i didnt see anything static that was at 50% of any sort of limit.
- tayloramy
Super User
Hi db042190,
This is a separate issue. The first issue was exceeding the max memory of your F4 capacity, this email is about reaching 50% of the CU limit for your capacity. If you open Capacity Metrics now, you should see the 50% CU usage in there.
To solve the first issue, you either need to upgrade your capacity, or make your model smaller.
Data reduction techniques for Import modeling - Power BI | Microsoft Learn
You could also split your model into multiple smaller models.
- FarhanJeelani
Hi db042190 ,
The error is accurate, and the reason the usage dashboard looks clean is that it can't show you what failed here.
CUs and storage are not the constraint. CUs measure CPU time, and the Storage tab is OneLake bytes on disk — an import model's in-memory footprint isn't in either one. Memory for semantic models is governed separately by Analysis Services resource governance, and the Fabric Capacity Metrics app doesn't expose those metrics at all. So you can be at 1% utilization with zero throttling and still get this.
The numbers in your error tells that:
- Database size before command execution: 1589 MB
- Memory limit granted: 1482 MB
- Consumed: 1484 MB
A full refresh needs roughly 2-3x the model's in-memory footprint, because the old copy stays resident while the new one is built, plus recalc on top. So a ~1.6 GB model wants somewhere around 3-5 GB of headroom and isn't getting close.
On the SKU side: F2, F4 and F8 all share the same 3 GB per-model ceiling, so bumping to F8 buys you nothing. F16 is the next real step at 5 GB. Also worth knowing that the 3 GB figure is an upper bound on model size, not a refresh budget — the docs note memory has to be reserved for refresh and query operations, so the usable number is lower. Fabric allocates dynamically too, which is why you got an odd 1482 MB rather than something round.
As for why it worked before and not today: the model grew past the tipping point, something else was resident on the capacity at that moment, or someone had a report open against the same model while the refresh ran. Query + refresh on one model stacks well past 2x.
What I'd do, in order:
1. Run VertiPaq Analyzer (DAX Studio or Tabular Editor) against the model via the XMLA endpoint. You'll almost always find one or two high-cardinality columns eating a third of the model. Datetime columns with seconds are the usual offender — split into date + time. Drop unused columns, and turn off auto date/time if it's on.
2. Move to incremental refresh, or drive partition-level refreshes through XMLA. The full-model refresh is what's killing you; one partition at a time keeps peak memory way down.
3. Check nothing else is querying the model during the refresh window.
4. Only look at F16 if optimization doesn't get you there. A 1.6 GB model is often 800 MB-1 GB after a proper cleanup, which sits comfortably inside F4.
One thing you can already cross off: at 1589 MB the model is above the 1 GB default, so Large semantic model storage format is clearly enabled.
If you want ongoing visibility into this, Workspace Monitoring captures AS engine events including memory, which is the gap the metrics app leaves.
Please mark this post as solution & let me know if this post helps you. Appreciate Kudos.
- db042190
thx farhan, the numbers (consumed before and new) are close enough and time of day of the 2nd failure late enough that i'm understanding and agreeing. But i wonder if the before or current on OTHER sm's not being refreshed at the same time competes with a refresh attempt on this guy? you are correct we did click large sm format as we were scurrying for a quick and dirty solution. one thing we wonder which we said to amy also is that essentially the same sm refreshes in a non fabric (long story) ws without issue and pro is in effect there. are pro ws's subject to the same storage restrictions?
- FarhanJeelani
db042190 The same refresh failing over and over is the key detail — it rules out concurrency. If another model were stealing headroom you'd see it fail sometimes, succeed others. Consistent failure means it doesn't fit on F4 at all: 1589 MB resident, full refresh needs old copy + new copy, grant is ~1482 MB. No quiet window fixes that.
And you won't find anything at 50% of a limit — the Capacity Metrics app has no memory metric. Everything in it is CU-seconds or storage bytes.
Quick unblock: run clearValues then full via XMLA (TMSL in SSMS or Tabular Editor). Clearing drops the resident copy first, so you need ~1x memory instead of 2x. Model sits empty if it then fails, so pick your timing. If it still fails, do it table by table.
{ "sequence": { "operations": [ { "refresh": { "type": "clearValues", "objects": [ { "database": "YourModel" } ] } }, { "refresh": { "type": "full", "objects": [ { "database": "YourModel" } ] } } ] } }Then VertiPaq Analyzer in DAX Studio to see which columns are eating the 1.6 GB — usually two or three. Datetimes with seconds are the classic; splitting date + time often drops 20-30%.
On sprawl: on a small F SKU every resident model competes for the same memory pool, so that debt has a cost you can point at.
Can you paste the email text? If it's a throttling or overage notice that's the CU limiter — separate issue.
- tayloramy
Hi db042190,
Each Fabric Capacity has a limited amount of memory for model refreshes. An F4 has a limit of 3GB, and that is shared across all models, so if you have multiple models refreshing at the same time, they will share that 3GB.
The memory limits for each capacity sku are here: What is Power BI Premium? - Microsoft Fabric | Microsoft Learn
See this blog post from Microsoft for more details: Fabric Capacity Scaling and Power BI - What happens when Power BI model guardrails are exceeded? | Microsoft Fabric Community- db042190
thx amy, we are getting our heads around this now. the same refresh fails over and over and while my eyes aren't on everyone and every schedule, i doubt refreshes are running always. i've informed my coworkers and explained the vertipaq engine a little to them in the communication. i took the opportunity to sprinkle a bit of a lecture on the sm sprawl and tech debt i already see getting out of hand as we rush visuals in to satisfy the growing pressure for such things. I'm going to read farhan's post now. Essentially the same sm refreshes without issue in a workaround (fabric was unusable) non fabric ws. Im guessing 3gig is not the limit in pro licensed ws's? There was a pretty important fix done there which i'll try to apply in the problematic fabric ws but my hopes arent high as that error was related to a misuse of the NOW (rather than UTCNOW) function. i'll post back here.
- db042190
- db042190
