Forum Discussion
Shortcut to deltatable on Onelake generates high CU
We have now succesfully reduced the load on the Fabric capacity to a low value, down from about 25 to 50%. The following steps were implemented:
- Turn off the "Keep your Direct Lake data up to date" option on the default semantic model in the Lakehouse
- Turn off the "Sync the default Power BI semantic model" in the SQL analytics endpoint
- Turn off the "Keep your Direct Lake data up to date" option on the considered semantic model
- Synch the model via the API every 5 minutes. Use a Logic app, Azure function or any service with timer function.
Every refresh of the semantic model now takes about 20 seconds.
The capacity now spends about 20/300 of the time to refresh model. Note that this solution introduce some additional delay between the data source and the report - up to 5 minutes. .
Disabling the default model semantic model had a major impact on the capacity load. Exactly what is going on in the background with this model is unclear.
For our use case, triggering model refresh only from PowerBI or another downstream load would be the ideal solution.
Thanks for the good answer v-veshwara-msft
In the meantime, we have done more research on this case. We are updating the table about 20 times per minute, which means that even if the framing operation lasts only a couple of seconds, it will be running more or less continuously. Hence the hight CU usage.
Our proposed solution is to disable the "Keep your Direct Lake data up to date" hoping it will disable framing operation triggered on every table change. We will set up a scheduled refresh every 5 minutes. Our theory is that this will reduce the number of framing operations with a factor of 100, which should reduce the CU.
Will update the post once we know the results.
Using a scheduled refresh does not work in our case, see following error message. Only 30 minute intervals allowed.
{
"error": {
"code": "InvalidRequest",
"message": "Refresh schedule time must be full or half hour (HH:00 or HH:30)"
}
}Next step is to create a function app that updates the semantic model every 5 minutes via REST call. Will kee updating...
We have now succesfully reduced the load on the Fabric capacity to a low value, down from about 25 to 50%. The following steps were implemented:
- Turn off the "Keep your Direct Lake data up to date" option on the default semantic model in the Lakehouse
- Turn off the "Sync the default Power BI semantic model" in the SQL analytics endpoint
- Turn off the "Keep your Direct Lake data up to date" option on the considered semantic model
- Synch the model via the API every 5 minutes. Use a Logic app, Azure function or any service with timer function.
Every refresh of the semantic model now takes about 20 seconds.
The capacity now spends about 20/300 of the time to refresh model. Note that this solution introduce some additional delay between the data source and the report - up to 5 minutes. .
Disabling the default model semantic model had a major impact on the capacity load. Exactly what is going on in the background with this model is unclear.
For our use case, triggering model refresh only from PowerBI or another downstream load would be the ideal solution.
v-veshwara-msftCommunity Support
Thanks for sharing the detailed resolution and steps you implemented. This is very helpful and will definitely benefit other community members facing similar capacity load issues with Direct Lake mode.
It's great to see that turning off the sync options and managing the semantic model refresh through an external timer-based approach significantly reduced the CU consumption. Your note about the impact of the default semantic model is particularly useful and highlights how background processes can affect capacity even when user activity is low.
Appreciate you taking the time to follow up with these insights.
Please continue to use the Fabric Community for any further queries or discussions.