Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Shape the future of the Fabric Community! Your insights matter. That’s why we created a quick survey to learn about your experience finding answers to technical questions. Take survey.

Reply
rlansing
Resolver I
Resolver I

Possible memory leak in Microsoft Mashup Evaluation Container?

I am having an issue with the Microsoft Mashup Evaluation Container using too much RAM on a computer with the following specs:

Core i7-4790K 4.00GHz

32 GB RAM

Windows 10 Pro 64-bit

February 2017 version of Power BI Desktop and latest On-Premise Gateway

 

When running data imported from Excel files, the evaluating takes a really long time followed by an even longer data loading process. During the evaluation phase the memory reaches 100% usage and then I believe falls into a thrashing death spiral (RAM to pagefile, pagefile to RAM, etc,,,). This has not been an issue before the latest update. Usually these larger data pulls would take a few minutes if not an hour or two to pull in the Excel data (extensive data model and a few Power Query custom functions), but it would never be this bad. A day and a half later there is no progress made on the data load, it is still saying loading and the computer is becomng unresponsive due to a lack or resources.

 

I converted all of my Excel files to CSVs and the loading times are dramatically improved, but just a few minutes ago the memory spiked again and stayed at 100% for a long time. When forcing the gateway and desktop closed, it seems to orphan the Mashup Evaluation Container, which is the real memory culprit. The orphaned Mashup Evaluation Containers (there are about six or more) then continue to use a high rate of RAM and Disk usage. I have to force them closed to (end task) to regain control of the computer.

 

Is there some setting I can check or is this a known issue with the latest version of the program?

1 ACCEPTED SOLUTION
rlansing
Resolver I
Resolver I

It looks like this problem has been solved!

One of the query steps is to merge tables. Originally this was based on three unique columns, then I created one column that was a unique identifier, but it was a long text string. I have finally been able to format this into a 19 digit whole number that is used to merge the queries. This looks like it was the issue, so it is now running faster and without using all available RAM.

View solution in original post

5 REPLIES 5
rlansing
Resolver I
Resolver I

It looks like this problem has been solved!

One of the query steps is to merge tables. Originally this was based on three unique columns, then I created one column that was a unique identifier, but it was a long text string. I have finally been able to format this into a 19 digit whole number that is used to merge the queries. This looks like it was the issue, so it is now running faster and without using all available RAM.

Well done.
Could you give more explanation about the merge that killed your RAM and how do you solved it?

 

Thank you.

I was merging two very large tables in an Outer Join fashion with three columns. I converted the columns to integers and that helped the process immensely. As well, I created a custom column that was a concatentation of the three prior to changing the data type, so there was only one column to merge on. Not sure if that helped, but I know the data type really helped.

Thank you. I will looking for this type of optimization in my query steps!

 

rlansing
Resolver I
Resolver I

 

Here is a screenshot of the memory usage

memusage.jpg

Helpful resources

Announcements
November Carousel

Fabric Community Update - November 2024

Find out what's new and trending in the Fabric Community.

Dec Fabric Community Survey

We want your feedback!

Your insights matter. That’s why we created a quick survey to learn about your experience finding answers to technical questions.

Nov PBI Update Carousel

Power BI Monthly Update - November 2024

Check out the November 2024 Power BI update to learn about new features.

Live Sessions with Fabric DB

Be one of the first to start using Fabric Databases

Starting December 3, join live sessions with database experts and the Fabric product team to learn just how easy it is to get started.