Forum Discussion
Impactful Individualmemory error doesnt seem right
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.
Super UserHi 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.
db042190thx 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.
- db042190
i think i pasted the email you are asking about. it was a warning about us being at 50% of capacity. i'm a newbie but in the capacity manager i didnt see anything history related about throttling or overages when i clicked those tabs. at the moment i'm looking at the granularity (in sql) of the author's fact query which results in about 12.7 million rows. i'm comparing it to the needs in his visuals. i verified that auto date isnt set here. unfortunately he has an as of date slicer which i'll need to think about otherwise i'd already summarize his core fact by month and year. but i was surprised ...when i simulated that granularity (mo and yr), i still end up with 7.8 million records which makes me think i'm already doing something wrong. either way, is a pro ws subject to the same 3gig limit?