Scheduled Refresh Causes Server Pagefile Usage to Grow Overtime

[Anonymous]

Hello!

Roughly nine or so months ago, upgraded from using an older SSRS system to using Power BI Report Server. currently use PBIRS for on-premis data reporting. We have several pagenated reports with subscriptions that we used thorughout the years and are now beginning to make use of Power BI reports as well. Many of my reports connect to either SQL or Oracle databases and run stored procedures to get the data. I have figured out how to get Data Refresh working for my reports and it works very well. 

However, soon after I learned how to build Power BI reports and set up auto refresh, our subscriptions stopped sending out one day. The SSRS database would claim the subscriptions have been sent but the emails never were actually sent out. I restarted the Power BI service on our vm server and the subscriptions automatically started running again. Upon much investigation and monitoring using Performance Monitor on our server, I noticed that after each scheduled refresh of my power bi reports that several Microsoft.Mashup.Container.NetFX40 processes would start running. Then after these processes are complete, the page file would settle down with usage slightly higher than previously. This process repeats itself many times and after about 3 days or so, the page file would be completely full and I would have to restart the Power BI Report Server service. This would release the pagefile memory until it would get used up again.

I came accross this issue where someone had a similar problem. The fix is to restrict data preview from downloading data in the background of each Power BI Report. I have attempted to integrate this fix but it does not reslove my issue. I am a bit at a loss of what to do.

Any extra insight would be greatly appreciated!

[ITGeek555]

Hi CBMann,  Power BI import mode report data resides in a tabular cube.  The cube is memory only.  When a scheduled refresh is fired the cube is rehydrated from the backend SQL Server database into memory (if not already in memory) and rebuilt.  If you are seeing page file activity then I would suggest you increase the amount of RAM assigned to the PBIRS server.  You can use the Power BI Report Server Capacity Planning white paper to help you. 

[Anonymous]

I upgraded the memory on the server from 12gb to 32gb. The whitepaper recommended 32gb for a smaller user group, but looking at the minimum memory requirements, Power BI report server recommends 4gb? I found that information here. https://docs.microsoft.com/en-us/power-bi/report-server/system-requirements

I am still getting a pretty bad memory leak though. Using Recource Monitor on the report server, I found that there are six processes named Microsoft.Mashup.Container.NetFX40.exe. It would be great to simply kill these processes every day when no refreshes are running. I have tested doing so and it did not effect the data retained in the Power BI file on the portal. The commit bytes on these processes are never released. So, as more data refreshes happen, the paging contininues to grow. At one point I had almost half of my memory completely free, but it made no difference. Would killing the mashup processes cause any problems I am unaware of? Is there a way to force them to release their commit bytes so that that memory and paging space can be used? 

Thanks!

[saj]

Thanks for this @Anonymous 

We have January Report Server version and find that performance of reports deteriorates over a couple of days after a server reboot until each report page / slicer change can take around 10 seconds (woefully slow).

We've been hunting for the issue for some time. We started using refresh schedules around 6 months ago which was about the time that performance started being an issue.

We'll now monitor Microsoft.Mashup.Container.NetFX40.exe in conjunction with performance and confirm definitively whether the 2 are related.

Thanks again, the needle is hopefully getting closer to being found!