Power BI Report Server Scheduled Refresh Bottleneck Problem

[gkc9]

We are experiencing a performance bottleneck in our Power BI Report Server environment. (january 2026 version)

We have around 1000 reports, each with multiple scheduled refreshes(total count app.1030) per day, which creates heavy load on the system.

We have already made some parameter changes in the Report Server configuration files to improve performance.

Aside from scaling out the environment, what other architectural or configuration changes would you recommend to handle this workload more efficiently?

Any best practices for optimizing PBIRS under high scheduled refresh load would be appreciated.

Best Regards,

[v-priyankata]

Hi @gkc9 

Thank you for reaching out to the Microsoft Fabric Forum Community.

@lbendlin @Nasif_Azam Thanks for the inputs.

I hope the information provided by users was helpful. If you still have questions, please don't hesitate to reach out to the community.

[v-priyankata]

Hi @gkc9 

Hope everything’s going smoothly on your end. I wanted to check if the issue got sorted. if you have any other issues please reach community.

[gkc9]

Hello,

Thank you for your considartion. We are using RS Engine on Virtual Machine. Despite having robust hardware, the system becomes unresponsive due to 100% CPU usage, primarily driven by the msmdsrv.exe process.

Environment Details:

• Hardware: VM with 16 vCPUs and 128 GB RAM.

• Workload: ~1000 reports with approximately 1030 scheduled refreshes per day.

• Observations: RAM usage is stable and within limits, but CPU spikes to 100% and stays there, causing the portal to hang.

Steps Taken (No significant improvement):

• Adjusted MemorySafetyMargin, MemoryThreshold, and CleanupCycleLimit.

• Increased tempDBInitialSize and adjusted MaxActiveReqForOneUser.

• IT has reviewed Local Security Policies and determined they are not the primary bottleneck.

Specific Questions:

1. Since msmdsrv.exe (Analysis Services Engine) is the main consumer of CPU, what are the best practices for Resource Governance in a shared PBIRS environment with 1000+ refreshes?

2. Would limiting CoordinatorExecutionMode or tuning ThreadPool\Process\MaxThreads within msmdsrv.ini be recommended for a 16-core setup to prevent thread contention?

3. Are there any known issues with the January 2026 build regarding how the Data Mashup Engine hands over tasks to the Analysis Services engine under parallel load?

4. Beyond staggering refresh slots, are there internal PBIRS queuing mechanisms we can tune to throttle the number of concurrent msmdsrv tasks?

Any architectural insights or advanced configuration suggestions would be greatly appreciated.

Best Regards,

[v-priyankata]

Hi @gkc9 

Thank you for reaching out to the Microsoft Fabric Forum Community.

The 100% CPU from msmdsrv.exe is happening because too many refreshes are running at the same time, and each one uses multiple CPU threads. This overloads the system, so even with good hardware, the portal hangs.

In Power BI Report Server, there’s no strong built-in control, so you need to limit how much runs in parallel. You can tune settings like CoordinatorExecutionMode (around 6–10) and MaxThreads (around 16–24) to reduce parallelism. Also, use MaxQueueThreads (8–12) to limit how many refreshes start together.

Maybe, the issue is too much parallel work not weak hardware. try Reduce concurrent refreshes and spread them out to stabilize the system.

If there are any deviations from your expectation please let us know we are happy to address.

Thanks.

[v-priyankata]

Hi @gkc9 

Hope everything’s going smoothly on your end. I wanted to check if the issue got sorted. if you have any other issues please reach community.

[Nasif_Azam]

Hey @gkc9,

At approximate1030 refreshes/day on a single PBIRS, the bottleneck is usually a mix of clustered schedules, duplicated models, and Analysis Services memory pressure from concurrent workspace loads. Try the following fixes:

1. Reduce Demand:

• Consolidate models: 1000 PBIX files almost always means heavy duplication. Move to a thin-report pattern like a small set of curated datasets with most reports built as live-connect on top. Fewer models = fewer refreshes.
• Enable incremental refresh: On large fact tables it often cuts refresh time and memory 80–90%.
• Push transformations to the source: Calculated tables/columns, M merges, and Table.Buffer steps inflate refresh time and Analysis Services memory. Move them into views or your ETL layer.
• Audit cadence: Pull ExecutionLog3 + catalog tables and find reports refreshing multiple times/day that nobody opens between refreshes. Retire or downgrade them.

2. Shape the schedule

• Query dbo.Schedule + dbo.ReportSchedule and bucket by 15-min intervals you will almost certainly find top-of-hour pile-ups. Spread with offsets and prioritize critical reports.
• Move to event-based refresh: Where possible trigger the PBIRS REST API (POST /CatalogItems({id})/Model.Refresh) from ADF, Fabric pipelines, or SSIS when upstream ETL finishes. Eliminates fixed-time clustering entirely.

3. PBIRS knobs often missed

• MaxQueueThreads: Cranking it higher usually hurts, since every concurrent refresh spawns an Analysis Services workspace competing for RAM. Sometimes capping lower improves throughput.
• ModelCleanupCycleMinutes / ModelExpirationMinutes: Lowering these evicts idle models faster and frees RAM between refresh waves.
• Analysis Services memory: Tune LowMemoryLimit, TotalMemoryLimit, VertiPaqPagingPolicy in msmdsrv.ini under PBIRS\ASEngine. Misconfigured Analysis Services memory is the #1 silent cause of PBIRS refresh slowdowns.
• Grant "Lock pages in memory" to the PBIRS service account.

4. Don't forget the source: In many "PBIRS bottleneck" cases, PBIRS is fine and the source DB is the real constraint. Profile source query times during peak refresh windows before blaming the server.

For Detailed Information:

• Troubleshoot scheduled refresh in Power BI Report Server
• Power BI report scheduled refresh in Power BI Report Server
• RsReportServer.config configuration file reference
• Analysis Services memory properties - msmdsrv.ini
• Incremental refresh for Power BI

Best Regards,
Nasif Azam

[gkc9]

Hello,

We are using RS engine on Virtual Machine. Despite having robust hardware, the system becomes unresponsive due to 100% CPU usage, primarily driven by the msmdsrv.exeprocess.

Environment Details:

• Hardware: VM with 16 vCPUs and 128 GB RAM.
• Workload: ~1000 reports with approximately 1030 scheduled refreshes per day.
• Observations: RAM usage is stable and within limits, but CPU spikes to 100% and stays there, causing the portal to hang.

Steps Taken (No significant improvement):

• Adjusted MemorySafetyMargin, MemoryThreshold, and CleanupCycleLimit.
• Increased tempDBInitialSize and adjusted MaxActiveReqForOneUser.
• IT has reviewed Local Security Policies and determined they are not the primary bottleneck.

Specific Questions:

1. Since msmdsrv.exe (Analysis Services Engine) is the main consumer of CPU, what are the best practices for Resource Governance in a shared PBIRS environment with 1000+ refreshes?
2. Would limiting CoordinatorExecutionMode or tuning ThreadPool\Process\MaxThreads within msmdsrv.inibe recommended for a 16-core setup to prevent thread contention?
3. Are there any known issues with the January 2026 buildregarding how the Data Mashup Engine hands over tasks to the Analysis Services engine under parallel load?
4. Beyond staggering refresh slots, are there internal PBIRS queuing mechanisms we can tune to throttle the number of concurrent msmdsrv tasks?

Any architectural insights or advanced configuration suggestions would be greatly appreciated.

Best Regards,

[lbendlin]

Challenge the developers on the refresh cadence.  Change their mindset from schedules towards event based refreshes (when the upstream data source has been updated).  Name and shame the developers with the biggest impact, and help them optimize their ETL.