Forum Discussion
On-Prem gatewy: Mashup.Container.NetFX45.exe killing server memory.
- 1 year ago
You're correct: Mashup.Container.NetFX45.exe is responsible for executing Power Query (M) logic, and when complex or inefficient M scripts run through the On-premises Data Gateway, they can consume significant resources. Let's address your concerns step by step:
🔍 1. How to identify which model/dataflow is consuming excessive memory?
- Enable Gateway Performance Logs: On the Gateway machine, go to:
C:\Program Files\On-premises data gateway\Microsoft.PowerBI.DataMovement.Pipeline.Diagnostics.log
This file tracks queries and their resource usage. Look for logs near the crash timestamp to correlate with the Mashup.Container PID. - Use Gateway Monitoring Features: In the Power BI Service, go to:
Settings > Manage Gateways > Diagnostics
Enable diagnostics and download logs, which will include query names, durations, and related mashup containers. - Correlation ID Tracking: If you enable verbose logging on the gateway (via config.json), you can capture the activity ID or request ID and trace it back to the workspace, report, or dataflow using the Power BI Service logs.
- Cloud Usage Insights: Use Power BI Activity Log or Log Analytics (if enabled) to trace scheduled refreshes and which reports/dataflows ran at the time of memory spikes.
🧩 2. Can we limit the memory usage of Mashup.Container.NetFX45.exe?
Unfortunately, there is no direct way to cap memory usage of this process. However, here are possible mitigations:
- Install the latest gateway version: Always use the latest version, as memory management improvements are continuously added.
- Split heavy refreshes: If a dataset processes many queries at once, split them into smaller refresh partitions.
- Optimize Power Query:
- Avoid nested joins, large in-memory merges, and buffer-heavy operations (like Table.Buffer).
- Use query folding where possible—let the source system do the heavy lifting.
- Use the gateway's MashupMaxContainerPoolSize setting (in Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config) to control the number of parallel mashup containers, thereby indirectly limiting total memory footprint.
☁️ 3. Can the On-Premises Gateway be used for cloud data?
Generally, the On-Prem Gateway is only invoked for sources that reside on-premises. However:
- If the cloud report combines cloud and on-prem data in a single query, Power BI may route everything through the gateway to preserve privacy levels and data joining logic.
- Check if your dataset uses Privacy Levels that force data to be combined at the gateway.
📌 Recommendations
- Upgrade to the latest gateway release.
- Enable diagnostic logging and correlate high-memory PIDs to model/dataflow activity.
- Profile and optimize Power Query scripts.
- Monitor and limit concurrent refreshes during peak hours.
- Investigate Gateway Performance Monitoring tools and Premium Metrics App if you're using capacity.
✔️ If my message helped solve your issue, please mark it as Resolved!
👍 If it was helpful, consider giving it a Kudos!
- Enable Gateway Performance Logs: On the Gateway machine, go to:
You're correct: Mashup.Container.NetFX45.exe is responsible for executing Power Query (M) logic, and when complex or inefficient M scripts run through the On-premises Data Gateway, they can consume significant resources. Let's address your concerns step by step:
🔍 1. How to identify which model/dataflow is consuming excessive memory?
- Enable Gateway Performance Logs: On the Gateway machine, go to:
C:\Program Files\On-premises data gateway\Microsoft.PowerBI.DataMovement.Pipeline.Diagnostics.log
This file tracks queries and their resource usage. Look for logs near the crash timestamp to correlate with the Mashup.Container PID. - Use Gateway Monitoring Features: In the Power BI Service, go to:
Settings > Manage Gateways > Diagnostics
Enable diagnostics and download logs, which will include query names, durations, and related mashup containers. - Correlation ID Tracking: If you enable verbose logging on the gateway (via config.json), you can capture the activity ID or request ID and trace it back to the workspace, report, or dataflow using the Power BI Service logs.
- Cloud Usage Insights: Use Power BI Activity Log or Log Analytics (if enabled) to trace scheduled refreshes and which reports/dataflows ran at the time of memory spikes.
🧩 2. Can we limit the memory usage of Mashup.Container.NetFX45.exe?
Unfortunately, there is no direct way to cap memory usage of this process. However, here are possible mitigations:
- Install the latest gateway version: Always use the latest version, as memory management improvements are continuously added.
- Split heavy refreshes: If a dataset processes many queries at once, split them into smaller refresh partitions.
- Optimize Power Query:
- Avoid nested joins, large in-memory merges, and buffer-heavy operations (like Table.Buffer).
- Use query folding where possible—let the source system do the heavy lifting.
- Use the gateway's MashupMaxContainerPoolSize setting (in Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config) to control the number of parallel mashup containers, thereby indirectly limiting total memory footprint.
☁️ 3. Can the On-Premises Gateway be used for cloud data?
Generally, the On-Prem Gateway is only invoked for sources that reside on-premises. However:
- If the cloud report combines cloud and on-prem data in a single query, Power BI may route everything through the gateway to preserve privacy levels and data joining logic.
- Check if your dataset uses Privacy Levels that force data to be combined at the gateway.
📌 Recommendations
- Upgrade to the latest gateway release.
- Enable diagnostic logging and correlate high-memory PIDs to model/dataflow activity.
- Profile and optimize Power Query scripts.
- Monitor and limit concurrent refreshes during peak hours.
- Investigate Gateway Performance Monitoring tools and Premium Metrics App if you're using capacity.
✔️ If my message helped solve your issue, please mark it as Resolved! 👍 If it was helpful, consider giving it a Kudos! |