CU Utilization Help Needed

[mheggie]

I'm hoping someone will be able to provide some guidance. 

We started work on developing a Fabric data warehouse 4 months ago.  We are working in an F2 capacity.  All has gone well until today.  Today, we've run across a scenario where our CU utlization has grown exponentially after very little activity.  All that has happened today amounts to a handful of data warehouse queries, most of which were from the queryinsights and INFORMATION_SCHEMA schemas.  There are no joins in the queries and all focus on 1 table (INFORMATION_SCHEMA) or 1 day of activity (queryinsights views). 

We've run all of these queries before.  Nothing is new.

After using over 100% of the capacity, I paused the capacity, waited ~30 minutes, and resumed so I could debug.  In looking at running requests (sys.dm_exec_requests and sys.dm_exec_sessions) , only 1 row returns - one tied to a queryinsights process.  After resuming, I ran 5-6 queries to debug - some against the queryinsights sessions and requests views and others against dm_exec_requests and dm_exec_sessions and the CU ulization has grown by 44,000.

I'm at a loss as to where to look to see what is causing this utilization. 

Any guidance / recommendations on where to look to find what is going on is greatly welcomed!

[mheggie · Accepted solution]

Thank you for these great tips.  I actually found the culprit - The rollout of Copilot for Fabric to all the smaller capacities.  When it rolls out to you, it will be enabled by default. 

Microsoft documentation provides the following "warning"  - "Enabling Copilot in Fabric for your entire tenant without adequate planning and preparation can lead to higher Fabric capacity utilization and other potential risks. Consider enabling Copilot in Fabric for specific security groups and workspaces only after you take the appropriate steps to prepare"

If you are running a small capacity, I recommend that you check for the rollout to your tenant and disable until you have time to test the impact.

[v-tsaipranay]

Hi @mheggie ,

Thank you for reaching out to the Microsoft Fabric Community.

The spike likely relates to internal system activities triggered by queries against telemetry views like queryinsights and INFORMATION_SCHEMA. These can sometimes cause expensive metadata scans, especially if historical or broad queries are executed.

Here are recommended steps to follow to resolve the issue:

• Query sys.dm_exec_requests for any long-running or system-triggered processes:

SELECT session_id, command, status, cpu_time, total_elapsed_time
FROM sys.dm_exec_requests
WHERE session_id > 50
ORDER BY total_elapsed_time DESC;

• When using queryinsights, always filter on recent timeframes (e.g., last 1 day) to avoid scanning full telemetry.

• After pausing and resuming capacity, some background rehydration tasks may consume CUs temporarily. Allow a 30–45 minute window for stabilization after resumption.

For more detailed information, you may find the following resources helpful:

What is the Microsoft Fabric Capacity Metrics app? - Microsoft Fabric | Microsoft Learn

Query Insights - Microsoft Fabric | Microsoft Learn

Pause and resume your capacity - Microsoft Fabric | Microsoft Learn

I hope this will resolve your issue, if you need any further assistance, feel free to reach out.

If this post helps, then please give us Kudos and consider Accept it as a solution to help the other members find it more quickly.

Thankyou.