Power BI Premium operations FAQ

For a comprehensive comparison covering pricing model, region pricing, Power BI Report Server, Power BI Embedded, Azure features, autoscale, Multi-Geo, and user licenses, see Key differences between Power BI Premium P SKUs and Fabric F SKUs.

Autoscaling is an optional feature of Power BI Premium, and is subject to two limits, each if which is configured by Power BI administrators:

• Proactive limit - a proactive limit sets the rate of expenses that Autoscale can generate, by limiting the number of autoscale v-cores a capacity can use. For example, by setting a maximum autoscale of v-cores to one v-core, you ensure that the maximum charge you can incur is 30 days of autoscaling with one v-core.

• Reactive limit - you can also set a reactive limit to the cost for autoscaling, by setting an expenditure limit on the Azure subscription used with autoscale. To set a reactive limit, do the following:

  • Set an Azure Policy to restrict the resource group to resources of type microsoft.powerbidedicated/autoscalevcores only.

  • Create an Action Group within your Azure budget which calls a custom Azure PowerShell Runbook to get and delete all resources in the resource group.

Power BI Premium evaluates your level of utilization by aggregating utilization records every 30 seconds. Each evaluation is composed of two different aggregations: Interactive utilization and background utilization.

Interactive utilization is evaluated by considering all the interactive operations that completed on or near the current half-minute evaluation cycle.

Background utilization is evaluated by considering all the background operations that completed during the past 24 hours, where each background operation contributes only 1/2,880 of its total CPU cost (there are 2,880 evaluation cycles in each 24-hour period).

A capacity consists of a defined number of v-cores. The Microsoft Fabric Capacity Metrics app tracks the utilization of your capacity v-cores. The CPU usage reported in the app drives the need to autoscale.

If you have a P1 subscription with eight v-cores, each evaluation cycle quota is 240 (8 × 30) seconds of CPU utilization. If the sum of both utilizations exceeds the total v-quota in your capacity, your capacity autoscales using an additional v-core for the next 24 hours.

Autoscale always looks at your current capacity size to evaluate how much resource you use. If you autoscaled using one v-core, your maximum capacity is now at 270 (240 + 1 × 30) seconds of CPU time in an evaluation cycle.

Autoscale always makes sure that no single interactive operation can consume all of your capacity, and you must have two or more interactive operations taking place in a single evaluation cycle to initiate autoscale.

During overload, if you don't autoscale throttling is applied.

Overload events that take place in the middle of the day are likely to affect many users. Overload events that take place in the middle of the night will probably affect only a handful of users. The overload score is designed to help you differentiate between these two overload events, so that you can single out the Power BI items (such as reports and datasets) that most impact your users.

The overload score is calculated in two steps:

1. The amount of CPU seconds belonging to interactive queries affected by an overload event is summed.

2. The value form step 1 is multiplied by the count of interactive operations that are affected by throttling.

Your metrics report dataset retains 30 to 45 days of data. Use the report to indicate how close you're to your capacity's maximum resources. If you save monthly snapshots, compare them to indicate trends of growth and extrapolate the rate to reach 100% utilization of your resources.

Utilization data doesn't currently indicate whether requests were throttled due to capacity being in interactive request delay mode. The information is added to the utilization app so admins can determine whether users experienced delays, and to what extent the delays are due to overload without autoscaling.

The Capacity management page in the Power BI admin portal has a utilization notification checkbox. Users can choose the threshold at which an alert is triggered (default is 80%) and the email address to which utilization alerts should be sent.

The Power BI service stores over 90 days of utilization data. Users who need longer data retention can use Bring Your Own Log Analytics (BYOLA) to store more utilization data.

Customers don't have visibility through utilization data to the memory footprint of their operations, and can't know ahead of time whether any of their operations is subject to failures.

On the left side of the utilization report, a bar chart visual displays utilization information between workspaces for the time span of the report. The bar chart visual can be used for chargebacks, providing each workspace represents a different business unit, cost center, or other entity to which chargebacks can apply.

When you buy a capacity, you get a predefined number of v-cores, as listed in Capacities and SKUs.

The Microsoft Fabric Capacity Metrics app helps you understand how your capacity is performing by displaying your capacity's CPU usage levels. To provide a way of measuring your capacity's performance, The app reports CPU usage for the number of v-cores your capacity has. Power BI makes throttling and autoscale decisions based on the data displayed in the app.

For information about Premium Per User (PPU), see the Power BI Premium Per User article.

Next steps

The following articles provide more information about Power BI Premium:

• What is Power BI Premium?
• Using Autoscale with Power BI Premium
• Extended Pro Trial activation
• Power BI Embedded FAQ

More questions? Try asking the Power BI Community