Embedded Capacity CPU Usage

[drussell_sayhii]

Hi all,

I'm using the Power BI Export Report content in PowerAutomate to export reports to PDF in an Embedded A SKU capacity (A1–A4). For each user in our system, we generate a filtered PDF version of a report and save it to SharePoint. This process works well functionally, but we’ve observed a puzzling behavior:

• During the export process, CPU usage on the capacity increases as expected.
• However, after all exports are complete, CPU usage remains elevated for exactly 24 hours.
• After 24 hours, CPU usage drops sharply back to baseline.

We’ve confirmed that:

• No dataset refreshes or interactive operations are occurring during this time.
• The Power BI Gen2 Metrics App shows no active jobs or background operations.
• According to the documentation, the export API returns a download URL valid for 24 hours, which streams the PDF file.

This leads us to suspect that the cached export file or rendering artifacts are being retained in memory or tied to the ScreenshotEngine, and that these resources are not released until the 24-hour URL expiration.

Questions:

1. Is the 24-hour CPU usage tied to the cached export stream or rendering engine?
2. Is there a way to manually release or invalidate the export cache once the file has been retrieved?
3. Are there any best practices for minimizing long-term CPU impact from large-scale PDF exports?

This behavior is making it difficult to scale capacity efficiently, as we must remain over-provisioned to avoid throttling interactive jobs—even when no active exports are running.

Any insights or guidance would be greatly appreciated!

Thanks,

David

[Poojara_D12 · Accepted solution]

Hi @drussell_sayhii 

What you’re experiencing with sustained high CPU usage for exactly 24 hours after completing PDF exports in Power BI Embedded A SKU capacity aligns with how the export API manages caching and resource allocation. When you export reports to PDF via the Power BI Export API, the service generates a cached export artifact—essentially a snapshot or rendering held in memory or temporary storage to enable the export file to be streamed via the provided URL, which remains valid for 24 hours. This cache or rendering engine resource is not immediately released after the export finishes, as the system keeps it available in case the client retries or re-downloads the file within the URL’s lifetime. Consequently, the CPU remains elevated because these rendering processes or cached data persist until the 24-hour expiration automatically clears them. Unfortunately, there is no documented or supported method to manually invalidate or release this cache earlier, so the resources remain reserved for the entire URL validity period. To minimize long-term CPU impact from large-scale PDF exports, best practices include scheduling exports to avoid peak interactive usage, batching exports where possible to reduce frequency, and considering alternative approaches like pre-generating reports or using incremental exports. Because this caching behavior is inherent to how the export API manages session consistency and download reliability, it requires careful capacity planning and potentially over-provisioning to ensure interactive workloads are not throttled by these ongoing export-related CPU demands.

[drussell_sayhii]

In my continued testing, I have found that increasing the environment size does have an impact, but not necessarily the impact I expected. When the environment size is twice what the workload requires (CPU usage does not exceed 50% of the available capacity), resources drop to zero after the spike, and I can immediately resize the environment back down to a minimum. However, when the environment size is set for efficiency (CPU usage reaches around 80% of the available capacity), resources are held for 24 hours, even after resetting the environment (pausing and starting).

Based on the behavior observed with the "oversized" environment, I am inclined to believe that my original theory about why the resources are held might not be accurate. Unfortunately, I do not fully understand why oversizing the environment has the impact that it does.

Your recommendations make sense and may ultimately be the solution. It just seems like a significant "old school" hack to throw hardware at the problem and hope it goes away.

David

[Anonymous]

Hi @drussell_sayhii,

Thanks for sharing those findings — they add a lot of clarity

At this time we are closing this thread. If you have any further issues, please start a new thread in the community forum, and we are here to assist you. Thankyou for your understanding and continuous support.
Thank you for being part of the Microsoft Fabric Community.

Regards,

Vinay Pabbu

[Anonymous]

Hi @drussell_sayhii,

As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided for the issue worked? or Let us know if you need any further assistance?
If our response addressed, please mark it as Accept as solution and click Yes if you found it helpful.

Regards,
Vinay Pabbu

[Anonymous]

Hi @drussell_sayhii,

As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided for the issue worked? or Let us know if you need any further assistance?
If our response addressed, please mark it as Accept as solution and click Yes if you found it helpful.

Regards,
Vinay Pabbu

[Anonymous]

Hi @drussell_sayhii,

Thank you for reaching out to Microsoft Fabric Community Forum.

Is the 24-hour CPU usage tied to the cached export stream or rendering engine?
Yes, most likely. The elevated CPU usage you're observing is likely tied to the ScreenshotEngine and internal memory/cache retained until the export URL expires.

Is there a way to manually release or invalidate the export cache once the file has been retrieved?
As of now, no official method exists to manually invalidate or release the export cache. You can raise a feature request through the Power BI Ideas forum to suggest adding this capability.

https://ideas.fabric.microsoft.com/ideas/search-ideas 

Are there any best practices for minimizing long-term CPU impact from large-scale PDF exports?
Use Higher SKU or Auto-Scale so your capacity can handle export bursts and release unused resources post-export.
Spread exports across different time windows to avoid spikes

If this post helps, then please consider Accepting as solution to help the other members find it more quickly, don't forget to give a "Kudos" – I’d truly appreciate it!

Regards,
Vinay Pabbu