PowerBI on Fabric get stuck

[Manojjain]

Hi All,

We recently migrated from PowerBI Premium to F64 capacity on Fabric. Here on fabric we are facing challenge on capacity Utilization. It has been observed that a single user can consume more than 200% of entire capacity. Therefore all other users are getting stuck and no reports run during that time. 

Also there is no option to kill the user session on fabric to reclaim the capacity for other users. This is really pathetic. Also it doesnt provide the session logs to see which report which is creating such problem.

I haven't seen this in other products where no feature to get the session logs and admin the user sessions. Below is the workaround provided by MS support team which is ridiculous.

"We have checked with our internal team regarding the automatic session termination for a specific user. Unfortunately, they have confirmed that this feature is not feasible at the moment.

However, there are alternative steps you can take to address the issue. You can identify the datasets and workspaces causing the problem and reassign them to different capacities or remove the access of the user consuming excessive capacity."

It would be greate help is someone can provide the workaround or possible solution for this problem.

Thanks

[Poojara_D12]

Hi @Manojjain 

After migrating from Power BI Premium to F64 Fabric capacity, we’ve encountered significant issues with capacity utilization and governance. One major concern is that a single user can monopolize over 200% of the entire capacity, effectively starving all other users of resources. During such episodes, report usage across the organization becomes unresponsive, causing widespread disruption. Compounding the issue, Fabric currently lacks a built-in session management mechanism—there is no way to view, monitor, or terminate active user sessions. This leaves administrators powerless to reclaim capacity or take immediate corrective action.

What’s more troubling is the lack of transparent session logs or diagnostics to help pinpoint the exact report or query causing the overload. This is unlike other enterprise-grade platforms where session-level monitoring and control are considered standard. Microsoft’s current workaround—suggesting admins manually identify heavy datasets or reassign users to other capacities—is inefficient, reactive, and operationally impractical, especially in dynamic and large-scale environments. Overall, this gap in Fabric’s capacity governance undermines its promise as an enterprise-grade solution and urgently needs attention to support real-world production workloads effectively.

[v-dineshya]

Hi @Manojjain ,

Thank you for reaching out to the Microsoft Community Forum.

Please check below things to fix the issue.

1. Use the Fabric Capacity Metrics App, which provides Compute View (tracks Capacity Unit utilization across workloads and users). Storage View (Monitors lakehouse and KQL database usage). Throttling Events (Identifies operations causing capacity overloads).

Note: This app helps admins which users or workloads are consuming excessive resources and plan corrective actions.

2. Assign high-demand workspaces to separate capacities. Use incremental refresh to reduce memory spikes. Prioritize datasets based on size and refresh frequency.

3. Even small datasets (~6GB) can trigger memory errors due to temporary spikes during refresh. The 25GB limit for F64 is misleading because only 50% is available for refresh operations.

4. Microsoft recommends three strategies when facing throttling, Optimize (Use incremental refresh, reduce dataset complexity). Scale Up (Move to higher capacity SKUs). Scale Out (Distribute workloads across multiple capacities).

Please refer below Microsoft document and community thread.

Evaluate and optimize your Microsoft Fabric capacity - Microsoft Fabric | Microsoft Learn

Solved: Re: Fabric F64 gives an out of memory error on res... - Microsoft Fabric Community

If this information is helpful, please “Accept it as a solution” and give a "kudos" to assist other community members in resolving similar issues more efficiently.

Regards,

Dinesh

[v-dineshya]

Hi @Manojjain ,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. And, if you have any further query do let us know.

Regards,

Dinesh

[Manojjain]

Hi @v-dineshya ,

Thanks for the followup. We are still facing challange to the fabric. Major problem is, a single user is consuming more than 200 capacity while running just 3-4 reports. We are also following with MS team. since its like 1 user bringing down the entire F64 capacity which is not acceptable. MS has to investigate it in detail and provide the root cause.

Thanks,

Manoj Jain

[v-dineshya]

Hi @Manojjain ,

Thank you for your response. As you menioned that , you are checking with support team. Have you created support ticket?. If yes please share the support ticket link.

Regards,

Dinesh

[Manojjain]

Here it is... Service request2506271420000666

[v-dineshya]

Hi @Manojjain ,

Thank you for sharing Service request ID. We would like to inform you that the support team is currently working on the issue with internal team. Kindly wait for a few moments for their response.

Regards,

Dinesh

[Manojjain]

Thanks for the update.. however its been long time and still no proper diagnostics has been provided and not getting from proper support from the team. I didnt expect this from MS Support team.

[v-dineshya]

Hi @Manojjain ,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. And, if you have any further query do let us know.

Regards,

Dinesh

[rohit1991]

Hi @Manojjain,
It sounds like you’re dealing with a really frustrating situation post-migration to Fabric F64 capacity. The fact that a single user can consume over 200% of capacity and block others is definitely concerning, especially without a way to manage or terminate sessions. You're right — the lack of session-level logs and real-time control makes it incredibly difficult to monitor and troubleshoot performance issues effectively.

While Microsoft’s suggestion to manually reassign datasets or revoke access might work temporarily, it’s not a scalable or practical long-term fix. One workaround some organizations use is to segment high-load workspaces into their own dedicated capacity, essentially isolating heavy users to protect broader usage. Also, implementing stricter data model optimization and usage limits at the report level may help mitigate impact. Hopefully Microsoft adds more robust admin tools soon, because session visibility and control really should be standard at this level.