Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Il throttling si verifica quando le operazioni consumano più secondi di unità di capacità (CU) di quanti ne consenta lo SKU di capacità. Le unità di capacità misurano la potenza di calcolo disponibile per ogni SKU. Una limitazione eccessiva può comportare un peggioramento dell'esperienza dell'utente finale. Un tenant di Microsoft Fabric può creare più capacità e assegnare aree di lavoro a una capacità specifica per la fatturazione e il dimensionamento.
Fabric applica il throttling al livello di capacità. Mentre una capacità, o un insieme di spazi di lavoro, potrebbe subire prestazioni ridotte a causa del sovraccarico, altre capacità potrebbero continuare a funzionare normalmente. Quando una capacità produce funzionalità come gli elementi OneLake e un'altra capacità li utilizza, lo stato di throttling della capacità che li utilizza determina se le chiamate all'elemento vengono limitate.
Come Fabric bilancia prestazioni e affidabilità
Fabric offre prestazioni rapide ai suoi clienti. Il completamento delle attività che potrebbero richiedere alcuni minuti in altre piattaforme può essere completato in pochi secondi in Fabric. Le operazioni di grandi dimensioni possono essere eseguite in qualsiasi momento della giornata senza la necessità di una pianificazione attenta perché Fabric distribuisce il calcolo per quelle operazioni su un periodo di tempo più lungo, senza rallentare il funzionamento operativo. Fabric consente questo comportamento utilizzando bursting e smoothing integrati. Queste caratteristiche permettono alle capacità di auto-gestirsi e di auto-guarire quando picchi temporanei di utilizzo avrebbero causato il guasto o il rallentamento di altri sistemi.
Bursting: Utilizza più capacità di calcolo rispetto alla capacità fornita da SKU
Per garantire prestazioni rapide, Fabric utilizza bursting per eseguire le operazioni il più velocemente possibile. Con il bursting, le operazioni possono temporaneamente utilizzare più risorse di calcolo rispetto a quelle allocate per lo SKU di capacità. Grazie al bursting, ottieni risultati senza dover aspettare. Una capacità minore può anche utilizzare il bursting per gestire operazioni più grandi che normalmente richiederebbero una capacità più costosa.
Smoothing: distribuire l'utilizzo della CU nei periodi futuri
Per evitare di penalizzarti quando le operazioni traggono vantaggio dai picchi di utilizzo, Fabric smussa, ovvero calcola la media, dell'utilizzo di CU di un'operazione su un periodo di tempo più lungo. Questo comportamento ti consente di usufruire di prestazioni sempre elevate senza throttling.
Lo smoothing distribuisce l'utilizzo del CU nei punti di tempo futuri. I punti di tempo in Fabric sono lunghi 30 secondi. Le successive 24 ore contengono 2.880 punti temporali. Fabric gestisce automaticamente la quantità di CU consumate in ogni punto temporale.
Il tipo di utilizzo di un'operazione determina il numero di punti temporali che Fabric utilizza per lo smussamento. Informazioni sulle operazioni del Fabric.
- Fabric smussa le operazioni interattive per un minimo di cinque minuti, e fino a 64 minuti a seconda di quanto consumo di CU consumano.
- Fabric distribuisce le operazioni in background nell’arco di 24 ore perché in genere hanno tempi di esecuzione lunghi e un elevato consumo di CU.
A causa del livellamento, solo una parte dell'utilizzo del CU per un'operazione si applica a ciascun punto temporale, riducendo così la limitazione complessiva. L'utilizzo delle CU levigate si accumula mentre le operazioni vengono eseguite. La capacità futura, cioè le CU disponibili nei momenti temporali futuri, paga per un uso fluido perché la capacità funziona continuamente.
Bursting e smoothing lavorano insieme per aiutarti a lavorare più facilmente. Ad esempio, di solito si dedica tempo a programmare i lavori e a distribuirli durante la giornata. Con il smoothing, Fabric distribuisce il costo di calcolo per i lavori in background su 24 ore. Di conseguenza, i job programmati possono essere eseguiti tutti contemporaneamente senza causare picchi che altrimenti bloccherebbero l'avvio dei lavori. Allo stesso tempo, puoi godere di prestazioni costantemente veloci senza aspettare che i lavori lenti si completino o senza perdere tempo a gestire i programmi.
Nota
Fabric non supporta il bursting e lo smoothing quando un amministratore della capacità abilita Autoscale Billing per Spark. In questo scenario, l'uso di Spark funziona in modalità pay-as-you-go, e i concetti di bursting e smoothing non si applicano.
Attivatori e stadi di limitazione
Anche se le capacità hanno un smoothing predefinito che riduce l'impatto dei picchi di utilizzo, è comunque possibile sovraccaricare una capacità eseguendo troppe operazioni.
La capacità limita automaticamente le nuove operazioni quando è sovraccarica. La limitazione avviene in passaggi progressivi per ridurre al minimo l'impatto su attività importanti come gli aggiornamenti dei dati.
Anche quando una capacità funziona oltre il 100% di utilizzo, Fabric non applica immediatamente il throttling. Invece, la capacità offre protezione dal superamento della capacità che ti consente di utilizzare 10 minuti di capacità futura senza subire limitazioni. Questo comportamento offre una protezione integrata limitata contro i picchi, garantendo però agli utenti prestazioni costantemente rapide senza interruzioni.
La limitazione inizia nel momento in cui una capacità esaurisce tutte le risorse CU per i successivi 10 minuti. La prima fase del throttling introduce ritardi di 20 secondi nelle nuove operazioni interattive. La seconda fase del throttling rifiuta le nuove operazioni interattive quando la capacità esaurisce tutte le risorse CU per l’ora successiva. Durante questa fase, le operazioni in background possono avviarsi e eseguirsi. La terza fase del throttling rifiuta tutte le nuove richieste, interattive e in background, quando la capacità esaurisce tutte le risorse CU disponibili previste per le 24 ore successive. La capacità continua a limitare le richieste fino a quando non avrai saldato le CU consumate.
Nota
Microsoft tenta di migliorare la flessibilità dei clienti nell'uso del servizio, bilanciando al contempo la necessità di gestire il loro utilizzo della capacità. Per questo motivo, Microsoft potrebbe modificare o aggiornare la politica di limitazione delle risorse Fabric.
La tabella seguente riassume i fattori di attivazione e le fasi del throttling.
| Utilizzo | Limite dei criteri | Impatto sull'esperienza |
|---|---|---|
| Utilizzo <= 10 minuti | Protezione dell'eccedenza | I processi possono usare 10 minuti di utilizzo della capacità futura senza incorrere in limitazioni. |
| 10 minuti < di utilizzo<= 60 minuti | Ritardo interattivo | Fabric ritarda di 20 secondi i lavori interattivi richiesti dall'utente all'invio. |
| 60 minuti < di utilizzo<= 24 ore | Rifiuto interattivo | Fabric rifiuta i lavori interattivi richiesti dall'utente. |
| Utilizzo > di 24 ore | Rifiuto del background | Fabric rifiuta tutte le richieste. |
Esempio: come il livellamento riduce la limitazione per un'operazione in background
Ecco un esempio illustrativo di come funziona il smoothing per un'operazione in background che ha consumato 1 ora CU (il suo utilizzo equivaleva a 1 CU per 1 ora). Fabric smussa le operazioni di background per 24 ore. Il contributo di un'operazione in background in un determinato momento è dato dalle ore CU dell'operazione divise per le ore CU dello SKU nel periodo di livellamento. Un F2 fornisce 2 CU, ovvero 48 ore CU al giorno (2 CU moltiplicate per 24 ore). Questo job contribuisce per 1 ora CU / 48 ore CU = ~2,1% in ciascun punto temporale. L'impatto sui limiti di throttling di 10 minuti e 60 minuti è anch'esso pari a ~2,1%.
Ecco i dettagli che supportano l'esempio:
1 ora CU = 3.600 secondi CU (1 CU moltiplicato per 60 minuti all'ora e 60 secondi al minuto).
Ogni punto temporale dura 30 secondi. In 24 ore sono presenti 2.880 punti di tempo (24 ore * 60 minuti * 2 punti di tempo al minuto).
Poiché lo smussamento distribuisce i 3.600 secondi di CU nell’arco di 24 ore, il processo contribuisce con 3.600 secondi di CU / 2.880 intervalli temporali a ciascun intervallo temporale di 30 secondi. Quindi contribuisce a 1,25 secondi CU per ogni punto temporale.
La percentuale di throttling di 10 minuti si basa sul totale delle CU disponibili nei successivi 10 minuti di tempo di attivazione della capacità.
Una capacità di tipo F2 fornisce 2 CU. In ogni momento di tempo, un F2 ha 2 CU moltiplicati per 30 secondi = 60 secondi CU di calcolo.
Il contributo del lavoro di background a ogni singolo punto temporale è 1,25 secondi CU / 60 secondi CU = ~2,1% di un singolo punto temporale.
In 10 minuti, il F2 ha 2 CU moltiplicati per 600 secondi = 1.200 CU secondi di calcolo.
La porzione del processo in background che il livellamento distribuisce uniformemente nei successivi 10 minuti di capacità è pari a 1,25 secondi CU moltiplicati per 20 intervalli temporali = 25 secondi CU.
Quindi, la percentuale di throttling a 10 minuti è di 25 secondi CU / 1.200 secondi CU = ~2,1%.
Analogamente, anche l'impatto percentuale di limitazione di 60 minuti del processo in background è pari a circa 2,1%.
Anche se l'operazione in background ha consumato più CU di quante siano disponibili nel successivo intervallo di 10 minuti (ne ha consumate sei volte tanto), la capacità F2 non subisce limitazioni perché lo smoothing distribuisce il totale delle CU nell'arco di 24 ore. A causa dello smussamento, solo una piccola parte delle UNITÀ di calcolo utilizzate si applica a qualsiasi singolo punto di tempo.
Eccedenze, trasporto e burndown
Quando le operazioni utilizzano più capacità di quella supportata dallo SKU in un singolo momento temporale, il sistema calcola un overage. Il sistema calcola le eccedenze dopo lo smussamento. Se le eccedenze superano la finestra di limitazione consentita di 10 minuti, diventano CU carryforward.
La protezione dell'eccedenza garantisce che la capacità non venga ridotta fino a quando la finestra di regolazione di 10 minuti non è piena. Riduce la frequenza dei ritardi interattivi causati da picchi temporanei di utilizzo.
Fabric applica le CU di riportazione a ogni punto temporale successivo. Se un timepoint non è pieno, le CU inutilizzate riducono la quantità delle CU riportate . Questa riduzione è burndown.
L'applicazione della limitazione continua fino a quando la capacità inutilizzata non copre tutte le unità di capacità riportate.
Monitoraggio delle capacità per la regolazione
Gli amministratori della capacità possono impostare avvisi via email per le soglie di capacità utilizzando gli Eventi di Panoramica della Capacità. Gli amministratori possono anche usare l'app delle metriche di capacità per esaminare i livelli di regolazione della capacità.
Ridimensionamento corretto e ottimizzazione di una capacità
Livelli di limitazione costantemente elevati indicano la necessità di bilanciare il carico tra più capacità o aumentare le dimensioni della capacità SKU. Per le SKU F, puoi scalare la capacità. Scalare tra SKU su lati opposti del confine F256 e F512 potrebbe portare a un'esperienza più lenta.
Come capire che si sta verificando la limitazione della capacità
Quando una capacità rifiuta le richieste, si vedono codici di errore specifici e testo di errore:
- Codice di stato
CapacityLimitExceeded - Messaggio di errore
Your organization's Fabric compute capacity has exceeded its limits. Try again later. - Messaggio di errore
Cannot load model due to reaching capacity limits
Nota
Le prestazioni lente sono spesso dovute al design di un oggetto. Solo a volte, le prestazioni lente sono dovute alla limitazione della capacità.
Quando una capacità è sovraccaricata, un amministratore della capacità può usare l'app Fabric Capacity Metrics per confermare lo strozzamento.
- La tabella Eventi di sistema nella pagina Calcolo mostra la cronologia degli eventi di regolazione.
- I grafici Throttling nella pagina Compute mostrano quando l'utilizzo regolare supera uno dei limiti di throttling.
Come arrestare la limitazione quando si verifica
Le capacità sono di riparazione automatica, quindi è sempre possibile attendere che lo stato di overload sia finito prima di inviare nuove richieste.
Tuttavia, per interrompere più rapidamente il throttling, puoi utilizzare le seguenti strategie.
Quando si usano le capacità di SKU F, per fermare la limitazione delle prestazioni:
- Aumentare temporaneamente lo SKU. Aumentando il tuo SKU, si esegue il burndown più velocemente perché ogni punto temporale ha una capacità inutilizzata maggiore.
- Pausa e poi riprendi il tuo lavoro. La sospensione di una capacità comporta un evento di fatturazione per l'utilizzo della capacità futura accumulato. Quando una capacità viene avviata o ripresa, non ha un utilizzo futuro della capacità in modo che possa accettare immediatamente nuove operazioni. La pausa può rendere indisponibili i contenuti assegnati alla capacità, quindi prima assicurati che la capacità non sia in uso.
- La fatturazione dell’eccedenza di capacità può anche evitare il throttling; tuttavia, costa tre volte la tariffa normale della capacità. Per ulteriori informazioni, vedi Abilita l'eccesso di capacità.
Quando si usano le funzionalità SKU P, per arrestare il throttling:
- Abilitare la scalabilità automatica per la capacità P.
Le operazioni in corso non sono limitate
La limitazione influisce solo sulle operazioni richieste dopo che la capacità inizia a limitare. Tutte le operazioni, comprese quelle a esecuzione prolungata che hai inviato prima che iniziasse il throttling, possono essere portate a termine. Questo comportamento ti assicura che le operazioni siano completate, anche durante i picchi di utilizzo delle CU.
Protezione della limitazione composta
In Fabric, un'operazione spesso provoca il completamento di altri elementi o carichi di lavoro. Esistono molti esempi, ma uno tipico è la visualizzazione di un report. Ogni visualizzazione nel report esegue una query su un modello semantico sottostante. Il modello semantico potrebbe anche leggere i dati di OneLake per fornire il risultato della query. Ognuna di queste richieste costituisce una catena.
Quando esiste una catena di chiamate, c'è il rischio di throttling cumulativo, che si verifica quando Fabric applica una limitazione più di una volta alla stessa richiesta. Fabric dispone di una protezione integrata contro il throttling composto che riduce la probabilità di throttling composto. I carichi di lavoro possono optare per questa protezione.
Quando i carichi di lavoro supportano la protezione dalla limitazione composta, Fabric limita una richiesta una sola volta per ogni capacità che partecipa alla catena. La decisione di limitazione si verifica all'avvio della richiesta e si applica a tutte le operazioni nella catena.
Se una catena dipende da più capacità, ciascuna capacità applica la limitazione una sola volta, sulla prima richiesta che riceve nella catena.
Le esperienze del carico di lavoro seguenti supportano la limitazione composta:
- Modelli semantici che si collegano ad altri modelli semantici usando DirectQuery.
- Query DAX dai report impaginati verso modelli semantici.
Il comportamento della limitazione è specifico per i carichi di lavoro del Fabric
Sebbene la maggior parte dei prodotti Fabric segua le regole di throttling menzionate sopra, esistono alcune eccezioni.
Ad esempio, gli eventstream Fabric hanno molte operazioni che possono durare anni dopo l'inizio. Limitare le nuove operazioni di eventstream non avrebbe senso, quindi Fabric riduce la quantità di risorse CU allocate per mantenere aperto il flusso finché la capacità non sarà di nuovo in regola.
Un'altra eccezione è Real-Time Intelligence, che non sarebbe in tempo reale se ritardasse le operazioni di 20 secondi. Di conseguenza, Real-Time Intelligence non applica la prima fase di limitazione con ritardi di 20 secondi a 10 minuti di capacità futura. Real-Time intelligence attende fino alla fase di rifiuto a 60 minuti di capacità futura per iniziare la limitazione. Questo comportamento garantisce che tu possa continuare a godere di prestazioni in tempo reale anche durante periodi di alta domanda.
Analogamente, Fabric riporta quasi tutte le operazioni nella categoria Warehouse come background per sfruttare la fluidizzazione delle attività 24 ore su 24 e permettere i modelli d'uso più flessibili. La classificazione di tutti i data warehousing come background impedisce che i picchi di utilizzo di CU attivino troppo rapidamente il rallentamento. Alcune richieste potrebbero attivare una catena di operazioni che Fabric limita in modo diverso. Quando un'operazione interattiva avvia una catena che include un'operazione in background, Fabric può limitare l'operazione in background trattandola come un'operazione interattiva.
Classificazioni interattive e in background per la limitazione e il lisciamento
Potresti notare che Fabric a volte classifica le operazioni come interattive e le smussa come sfondo, o viceversa. Questa distinzione avviene perché i sistemi di throttling di Fabric devono applicare regole di throttling prima che una richiesta inizi a essere eseguita.
Il sistema di limitazione tenta di classificare in modo accurato le operazioni al momento dell'invio. A volte quando un'operazione inizia a essere eseguita, diventano disponibili informazioni più dettagliate che modificano la categorizzazione. In scenari ambigui, il sistema di limitazione torna a classificare le operazioni come background, cosa che è nel tuo interesse.
Monitorare le eccedenze e le operazioni rifiutate
Per verificare se la tua capacità è sovraccarica, consulta il grafico di utilizzonell'app Microsoft Fabric Capacity Metrics. Un picco che supera la riga indica un sovraccarico. Per analizzare ulteriormente l'eccedenza, approfondisci nella pagina dei punti temporali. Poi rivedi sia le operazioni interattive che quelle in background per vedere quali hanno causato gli overage.
Poiché un utilizzo superiore al 100% non implica automaticamente una limitazione delle prestazioni, usa il grafico della limitazione per valutare gli sforamenti. Da lì, apri una tabella che mostra i minuti rimanenti al burndown, un grafico con aggiunte, burndown e percentuale cumulata, e altro ancora. Minuti per il burn-down stima il tempo necessario per il burn-down se non vengono effettuate altre operazioni nella capacità operativa.
Per visualizzare una cronologia visiva di eventuali eccessi di capacità, inclusi riporto, cumulativi e andamento residuo dei dati di utilizzo, passa alla scheda Overages. Modifica la scala visiva degli eccessi per mostrare 10 minuti, 60 minuti e 24 ore.
Il drilldown dell'app Microsoft Fabric Capacity Metrics mostra operazioni che Fabric ha respinto durante un evento di throttling. Le informazioni su queste operazioni sono limitate perché non sono mai iniziate. Puoi vedere il prodotto, l'utente, l'ID operativo e l'orario della richiesta. Quando Fabric rifiuta una richiesta, gli utenti finali ricevono un messaggio di errore che chiede loro di riprovare in seguito.
Risorse di calcolo fatturabili e non fatturabili nei calcoli relativi al throttling
Quando si esamina l'utilizzo della capacità nell'app per le metriche della capacità, alcune operazioni sono fatturabili e altre non fatturabili. I calcoli di throttling includono solo le operazioni fatturabili. Alcune funzionalità di anteprima possono generare operazioni non fatturabili. Usa operazioni non fatturabili per pianificare in anticipo, così da dimensionare correttamente la tua capacità per quando queste funzionalità di anteprima diventeranno fatturabili.
Contenuto correlato
- Per monitorare le capacità di Fabric, installare l'app Microsoft Fabric Capacity Metrics.
- Come ridimensionare la capacità.
- Esplora gli eventi della panoramica della capacità di Fabric nel Fabric Real-Time hub