Forum Discussion
Trying to understand refresh memory usage
The numbers actually fit a known pattern. The F32 capacity has a 10 GB cap per semantic model, which the engine treats as 10,240 MB. While a refresh is running, AS keeps the current copy of the model in memory so queries are not blocked, then builds the new copy beside it. The space available to the refresh is therefore the cap minus the current database size:
10,240 MB - 1,986 MB = 8,254 MB
That closely matches the "memory limit 8253 MB" you are seeing in the error.
For the 8 to 9 GB peak during refresh, that is normal. AS has to read source data, build dictionaries, sort columns, and produce the compressed column store, all of which run with intermediate structures that are much larger than the final compressed size. A working set of roughly 2x to 3x the final model is typical, so a model that lands at 2.76 GB can spike to 8 to 9 GB while being built.
You can watch it live from a tool like DAX Studio while the refresh runs:
SELECT * FROM $SYSTEM.DISCOVER_MEMORYUSAGE
In the service, the Fabric Capacity Metrics app exposes the same refresh memory events per operation.
If this helped, a thumbs up and accepting the solution would be appreciated.
Best regards,
Shai Karmani
The numbers actually fit a known pattern. The F32 capacity has a 10 GB cap per semantic model, which the engine treats as 10,240 MB. While a refresh is running, AS keeps the current copy of the model in memory so queries are not blocked, then builds the new copy beside it. The space available to the refresh is therefore the cap minus the current database size:
10,240 MB - 1,986 MB = 8,254 MB
That closely matches the "memory limit 8253 MB" you are seeing in the error.
For the 8 to 9 GB peak during refresh, that is normal. AS has to read source data, build dictionaries, sort columns, and produce the compressed column store, all of which run with intermediate structures that are much larger than the final compressed size. A working set of roughly 2x to 3x the final model is typical, so a model that lands at 2.76 GB can spike to 8 to 9 GB while being built.
You can watch it live from a tool like DAX Studio while the refresh runs:
SELECT * FROM $SYSTEM.DISCOVER_MEMORYUSAGE
In the service, the Fabric Capacity Metrics app exposes the same refresh memory events per operation.
If this helped, a thumbs up and accepting the solution would be appreciated.
Best regards,
Shai Karmani