Report Server on Virtual Machine Problem

[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,

[v-sgandrathi · Accepted solution]

Hi @gkc9,

You’re heading in the right direction! Since the issue shows up across different versions, it’s more likely tied to workload concurrency and configuration than a specific bug.

When multiple refresh operations happen at the same time, the Analysis Services engine (msmdsrv.exe) will use all available CPU, which can push usage to 100%, especially with high concurrency.

To help, you can tweak CoordinatorExecutionMode (like setting it to 6–8 on a 16-core VM) to cut down on conflicts between jobs. Adjusting ThreadPool settings like MaxThreads is possible, but bumping them up usually makes CPU pressure worse, so it’s best to be careful there.

The easiest way to keep CPU stable is to manage how and when refreshes happen, PBIRS doesn’t throttle well on its own, so staggering schedules, separating heavy and light datasets, and avoiding big refresh bursts at the same time can really help.

Also, simplifying your models (like cutting down on heavy Power Query steps or large cardinality) and moving transformations upstream can lighten the load. If you can’t reduce the workload, splitting it across multiple PBIRS instances is worth considering. Basically, balancing parallelism and refresh timing is the way to go, rather than relying on a single SSAS tweak.

Thank you.

[ArwaAldoud]

Hi @gkc9 

This looks more like a high parallel refresh workload issue, where too many concurrent refreshes are driving msmdsrv CPU to 100%, rather than a hardware limitation.

There is a related discussion about msmdsrv restarts and SQLDmpr events in the January 2026 build under heavy load:
https://community.fabric.microsoft.com/t5/Report-Server/Power-BI-Report-Server-January-2026-msmdsrv-...

While that case involves crashes/restarts (stability issue) and your scenario is CPU saturation (performance issue), both may be related to how the engine handles concurrent workloads in this version.

 It’s recommended to verify you're running the latest patched version (March 2, 2026 update):
https://www.microsoft.com/en-us/download/details.aspx?id=105943

If this response was helpful, please accept it as a solution and give kudos to support other community members

[gkc9]

Hello, 

Thank you for your response. 

We’ve been hitting 100% CPU on msmdsrv.exe during parallel refreshes, and actually, we saw the same thing happening back in the January 2025 version too.

Since it persists across different versions, I’m starting to think it's a configuration issue rather than a specific bug. Do you think there are any specific Analysis Services (SSAS) settings or properties we could tweak to throttle this load and stabilize the CPU?