Forum Discussion

gkc9's avatar
gkc9
Frequent Visitor
4 months ago
Solved

Power BI Report Server Scheduled Refresh Bottleneck Problem

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.103...
"Power BI Report Server “
Power BI Report Service - Scheduled Refresh
  • v-priyankata's avatar
    v-priyankata
    4 months ago

    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.

Nasif_Azam's avatar
Nasif_Azam
Super User
4 months ago

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:

 

Best Regards,
Nasif Azam

 

gkc9's avatar
gkc9
Frequent Visitor
4 months ago

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,