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.
Community SupportHI Anonymous ,
Thanks for posting in Microsoft Fabric Community.
Based on your description, the high CU usage seems to be linked to how the semantic model interacts with the Delta table metadata via the shortcut, particularly through repeated access to the _delta_log folder in Direct Lake mode. Even without frequent report usage, the model might still be performing background operations such as schema validation or metadata refresh.
You've already seen a reduction by turning off sync for the default model, which confirms that metadata sync activity contributes significantly to the load. Some additional optimizations that can help reduce CU usage further include reviewing dataset settings in the workspace to ensure there's no scheduled refresh, auto page refresh, or model validation being triggered automatically. Also, simplifying the semantic model by limiting calculated columns, relationships, and expensive measures can help reduce background processing.
From the Delta table side, enabling frequent checkpointing on the delta writer helps limit the number of JSON files in the _delta_log folder that need to be scanned, reducing metadata read overhead. Compacting small files and maintaining a clean log structure can also reduce CU usage.
To further understand where the CU is being consumed, you can review usage patterns using the Fabric Capacity Metrics app, which provides detailed insights into resource consumption by individual items like semantic models and refresh activities.
This blog post outlines practical tips to optimize Direct Lake mode usage and might be helpful in your case:
https://community.fabric.microsoft.com/t5/Power-BI-Community-Blog/Optimizing-Direct-Lake-Mode-in-Microsoft-Fabric-A-Quick-Guide/ba-p/4373505
Hope this helps. Please reach out for further assistance.
If this post helps, then please consider to give a kudos and Accept as the solution to help the other members find it more quickly.
Thank you.