Forum Discussion
Embedded Capacity CPU Usage
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.
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
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