Forum Discussion
PublishModel fails with ImageLoad on High CPU consumption
Hi,
thanks everyone.
In the moment I go this way with restarting of failed reports at the end of the batch.
I dont know if deeper debugging and configuration of analysis services would really help, and is worth the effort.
I found also this article:
Solved: Re: Power BI Report Server Scheduled Refresh Bottl... - Microsoft Fabric Community
and
Analysis Services thread pool properties | Microsoft Learn
where I can play around with Affinitygroups and thread definitions. But how to find out which ThreadPool is the problem?
Maybe someone got already that deep in configuration of analysis service, and can give a hint how to proceed and if it makes sense here to investigate deeper.
Maybe the only chance is to throttle by maxQueueThreads, but I would like to have the optimal throughput of refreshing reports after the daily load of the DWH is done. And hard throtteling on the number of refreshes.. dont know.. Sounds like a workaround as well.
regards,
Stefan
Super UserHi stefanp2 I'm not sure but in this case I would treat the error as a resource/concurrency problem first, not as an ImageLoad bug.
From the log, the important part is this:
Starting Streaming model to Analysis Server
...
ImageLoad(...)
The connection either timed out or was lost
...
An existing connection was closed by the remote host
This usually means Power BI Report Server was trying to publish/load the refreshed model into the local Analysis Services engine, but the AS process became too busy or stopped responding long enough that the connection was closed.
Because you also see 8 CPUs at maximum usage and 4 report refreshes running at the same time, the most likely root cause is CPU saturation during model processing/publishing.
My suggestion is to start with these actions, in this order:
1. Do not refresh all 4 reports at the same time
2. Check whether msmdsrv.exe is the CPU bottleneck
If msmdsrv.exe is consuming most of the CPU, then the problem is mainly the internal Analysis Services model processing/publishing step. Similar PBIRS cases report high CPU caused by msmdsrv.exe during many scheduled refreshes
3. Optimise the PBIX models
Increasing timeout values may hide the symptom, but it will not fix the CPU pressure. If possible, move heavy calculated columns from DAX into Power Query or, even better, into the source database. There are refresh timeout cases where moving calculated columns to the import/transformation step solved the problem.