Capacidade & CU Fundamentos

Equipe FabricMetrics·Publicado 12 mar 2026·Atualizado 24 jul 2026·11 min de leitura

1. Throttling não é lentidão — é cobrança

Throttling é o mecanismo que a capacidade usa para te obrigar a pagar a conta de CU que você já gastou. Quando o consumo projetado da sua capacidade passa do que a SKU entrega, o Fabric não desliga nada: ele começa a atrasar e depois a rejeitar requisições até que o excedente seja quitado.

Essa distinção é a coisa mais importante do artigo. Um relatório lento pode ser DAX ruim, modelo mal desenhado, DirectQuery mal pensado. Throttling é diferente: todos os relatórios da capacidade ficam lentos ao mesmo tempo, incluindo os que sempre foram rápidos. Se apenas um relatório está ruim, não é throttling. Se a capacidade inteira está ruim ao mesmo tempo, provavelmente é.

2. Smoothing: por que o consumo de agora não é o consumo de agora

O Fabric não cobra picos instantâneos. Ele distribui o consumo de cada operação ao longo do tempo — smoothing — e essa distribuição depende do tipo de operação:

• Interativas (abrir relatório, filtrar visual, consulta DAX vinda do usuário): suavizadas ao longo de 5 minutos.
• Background (refresh de semantic model, Dataflow Gen2, pipeline, notebook, job Spark): suavizadas ao longo de 24 horas.

A consequência prática é brutal: o refresh gigante das 2h da manhã não aparece no gráfico como um pico às 2h. Ele aparece como um platô que se arrasta pelas 24 horas seguintes — inclusive às 9h04, quando os 300 usuários chegam. O throttling da manhã foi criado de madrugada.

3. Bursting e a dívida de CU

Bursting é o oposto do smoothing: a capacidade permite que uma operação consuma, por instantes, mais CU do que a SKU nominal oferece. Uma F8 pode entregar muito mais que 8 CU para um refresh terminar rápido. O tempo de execução cai — o custo, não. O excedente vira carry forward: uma dívida que a capacidade vai amortizar (burndown) nos timepoints seguintes.

Enquanto a soma de dívida projetada cabe em menos de 10 minutos de capacidade futura, nada acontece. É exatamente para isso que o bursting existe. Acima disso, começa a escada.

4. Os três estágios do throttling

A escada é definida pelo consumo futuro — quanto tempo de capacidade sua dívida já reservou adiante:

Consumo futuro acumulado	Estágio	O que o Fabric faz	O que o usuário sente
Até 10 min	Bursting protegido	Absorve o pico, sem penalidade	Nada
10 min a 60 min	Interactive Delay	Adiciona ~20 s a cada requisição interativa	“O Power BI está lentíssimo hoje”
60 min a 24 h	Interactive Rejection	Rejeita requisições interativas; jobs background seguem	Erro ao abrir relatório; refresh ainda roda
Acima de 24 h	Background Rejection	Rejeita tudo, inclusive refresh e pipelines	Plataforma parada

Opinião: o estágio mais perigoso é o primeiro. Interactive Delay não gera ticket, gera desconfiança. As pessoas param de usar o relatório e ninguém abre incidente.

Um detalhe que quase ninguém explica: os percentuais de throttling do Capacity Metrics são razões, não “gravidade”. Um Interactive Delay de 250% significa que o Fabric está tentando encaixar 25 minutos de consumo nos próximos 10 minutos. Um Background Rejection de 250% significa 2,5 vezes o orçamento diário da SKU — nesse ponto, a conta leva cerca de 36 horas para voltar a 100%.

5. Como confirmar throttling no Capacity Metrics

O Microsoft Fabric Capacity Metrics App responde a essa pergunta em quatro passos. Faça sempre nesta ordem:

1. System overview / Compute: encontre o timepoint em que o CU% passou de 100. Anote o horário exato.
2. Aba de throttling: confirme qual estágio estava ativo naquele intervalo (delay, rejeição interativa, rejeição background).
3. Overages / carry forward: leia Add % (dívida adicionada), Burndown % (dívida paga) e Cumulative %. Se o cumulativo cresce por horas, o problema é estrutural, não um pico.
4. Timepoint detail: clique no timepoint e ordene as operações por CU(s). Aqui aparece o culpado — quase sempre uma operação background que começou horas antes.

Se você precisa dos dados fora do app — para um painel próprio ou um alerta — a lista de capacidades e seu estado vêm da API do Fabric:

GET https://api.fabric.microsoft.com/v1/capacities
Authorization: Bearer <token>

# resposta (recortada)
{ "value": [
    { "id": "a1b2c3d4-...", "displayName": "cap-prod-br", "sku": "F8", "state": "Active" },
    { "id": "e5f6a7b8-...", "displayName": "cap-dev-br",  "sku": "F2", "state": "Paused" }
] }

6. As cinco causas que respondem por quase todo throttling que já vimos

1. Refresh full de modelo grande no horário errado. Modelo import de dezenas de GB recarregado inteiro toda madrugada. Resolve-se com refresh incremental, não com SKU maior.
2. Dataflow Gen2 com staging ligado sem necessidade. Cada staging escreve e lê de novo. É a fonte de CU invisível mais comum que encontramos.
3. Dev, teste e produção na mesma capacidade. Um notebook experimental de um analista derruba o relatório do diretor. Separar capacidades é governança, não luxo.
4. DirectQuery/DirectLake em relatório de alto tráfego sem agregação. Cada filtro do usuário é uma consulta no engine. Multiplique por 200 pessoas.
5. Jobs Spark concorrendo com a janela de refresh. Dois consumidores pesados na mesma hora somam dívida que nenhum dos dois criaria sozinho.

7. Playbook das próximas 24 horas

Em ordem de retorno sobre esforço:

• Mover as operações background pesadas para fora da janela em que o consumo suavizado encosta no pico de uso interativo.
• Ligar refresh incremental nos dois ou três modelos que dominam a lista de CU(s).
• Desligar staging nos Dataflows Gen2 que não precisam dele.
• Ativar surge protection para impedir que jobs background estourem a capacidade e derrubem o interativo.
• Só então avaliar SKU maior — com o número na mão, não com a sensação.

8. O que não fazer

• Pausar a capacidade para “zerar” a dívida. Pausar liquida o carry forward imediatamente — e cobra. É uma decisão financeira, não um reset.
• Escalar por pânico. Dobrar a SKU sem corrigir a causa dobra o custo e adia o mesmo problema por alguns meses.
• Culpar o autor do relatório antes de abrir o timepoint. Em nove de dez casos, o relatório era a vítima.

---

Perguntas frequentes

Capacidade & CU Como analisar o Capacity Metrics

A ordem de leitura das abas e as perguntas que o app responde bem.

9 min de leitura Capacidade & CU Comparativo F2 x F4 x F8

Onde cada SKU quebra: usuários, tamanho de modelo, janela de refresh.

11 min de leitura

Criado e mantido pela PRS Tecnologia para contribuir com a comunidade técnica de dados. Site independente, sem vínculo com a Microsoft e não oficial: não representa posições da empresa. Microsoft, Microsoft Fabric e Power BI são marcas de seus respectivos proprietários. · © 2026 · fabricmetrics.com.br

powerbiembed.com.brfabricboard.com.br