Politica di Fabric sulla limitazione.

La limitazione si verifica quando le operazioni utilizzano più unità di calcolo secondi (CU) rispetto allo SKU di capacità consentito. 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.

La limitazione viene applicata a livello di capacità, vale a dire che, mentre una capacità o una serie di aree di lavoro potrebbe riscontrare una riduzione delle prestazioni a causa dell'overload, altre capacità potrebbero continuare a funzionare normalmente. Nei casi in cui alcune funzionalità, come gli artefatti OneLake, vengano prodotte in una capacità e utilizzate da un'altra, lo stato di limitazione della capacità di utilizzo determina se le chiamate all'artefatto vengono limitate.

In equilibrio tra prestazioni e affidabilità

Fabric è progettato per offrire prestazioni rapide ai 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 del giorno senza la necessità di un'attenta pianificazione perché il calcolo per tali operazioni viene distribuito in un periodo di tempo più lungo, senza rallentare l'operazione. L'infrastruttura consente di usare bursting e smoothing predefiniti. Consentono ai sistemi di capacità di autogestirsi e autoripararsi quando i picchi temporanei di utilizzo altrimenti causerebbero malfunzionamenti o rallentamenti in altri sistemi.

Scoppio

Per garantire prestazioni veloci, Fabric usa il bursting per consentire l'esecuzione delle operazioni il più velocemente possibile. Il bursting consente alle operazioni di utilizzare temporaneamente più risorse di calcolo rispetto a quelle assegnate per lo SKU di capacità. A causa del bursting, gli utenti ottengono rapidamente risultati senza attendere. Il bursting consente anche di eseguire operazioni più grandi con una capacità più piccola, che normalmente richiederebbe una capacità più costosa.

Smussatura

Per evitare di penalizzare gli utenti quando le operazioni traggono vantaggio dal bursting, Fabric regola, o media, l'utilizzo di CU di un'operazione su un intervallo di tempo più lungo. Questo comportamento garantisce agli utenti prestazioni costantemente veloci senza riscontrare limitazioni.

Lo smoothing distribuisce l'utilizzo del CU nei punti di tempo futuri. I punti di tempo in Fabric sono lunghi 30 secondi. Nelle prossime 24 ore sono presenti 2.880 punti di tempo. Fabric gestisce automaticamente la quantità di CUs di consumo in ogni istante.

Il tipo di utilizzo di un'operazione determina il numero di punti di tempo usati per lo smussamento. Informazioni sulle operazioni del Fabric.

• Le operazioni interattive vengono regolate su un minimo di cinque minuti e fino a 64 minuti a seconda della quantità di consumo di CU.
• Le operazioni in background vengono ottimizzate in un periodo 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. L'utilizzo senza problemi viene pagato per la capacità futura, ovvero le CPU disponibili nei punti di tempo futuri, perché la capacità è in esecuzione in modo continuo.

Il bursting e lo smussamento interagiscono per rendere più semplice per gli utenti della capacità di svolgere il proprio lavoro. Ad esempio, gli utenti dedicano in genere tempo a pianificare i processi e distribuirli nel corso della giornata. Con lo smussamento, il costo di elaborazione per i processi in background è spalmato nell'arco di 24 ore. Ciò significa che i processi pianificati possono essere eseguiti contemporaneamente senza causare picchi che altrimenti bloccano l'avvio dei processi. Allo stesso tempo, gli utenti possono godere di prestazioni costantemente veloci senza attendere il completamento di processi lenti o sprecare tempo durante la gestione delle pianificazioni dei processi.

Nota

La modalità Bursting e Smoothing non sono supportate quando un amministratore di risorse ha attivato la fatturazione automatica della scalabilità per Spark. In questo scenario, l'utilizzo di Spark funziona in modalità con pagamento in base al consumoYou-Go e i concetti di bursting e smoothing non si applicano.

Trigger e fasi della 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 è sottoposta a sovraccarico. 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 100% di utilizzo, Fabric non applica immediatamente la limitazione. La capacità garantisce invece la protezione dell'eccedenza che consente l'utilizzo di 10 minuti di capacità futura senza limitazioni. Questo comportamento offre una protezione integrata limitata da picchi, offrendo agli utenti prestazioni costantemente veloci senza interruzioni.

La limitazione inizia nel momento in cui una capacità esaurisce tutte le risorse CU per i successivi 10 minuti. La prima fase della limitazione applica un ritardo di 20 secondi alle nuove operazioni interattive. La seconda fase della limitazione rifiuta le nuove operazioni interattive quando una capacità esaurisce tutte le risorse di CU per la prossima ora. Durante questa fase, le operazioni in background possono essere avviate ed eseguite. La terza fase della gestione del rifiuto limita tutte le nuove richieste, interattive e in background, quando tutte le risorse CU disponibili sono completamente utilizzate per le prossime 24 ore. La capacità continua a limitare le richieste fino a quando i CU consumati non vengono saldati.

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 di Fabric.

La tabella riepiloga i trigger e le fasi di limitazione.

Utilizzo	Limiti della politica	Impatto sull'esperienza della politica della piattaforma
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	I processi interattivi richiesti dall'utente sono ritardati di 20 secondi all'invio.
60 minuti < di utilizzo<= 24 ore	Rifiuto interattivo	I processi interattivi richiesti dall'utente vengono rifiutati.
Utilizzo > di 24 ore	Rifiuto in background	Tutte le richieste vengono rifiutate.

Esempio di attenuazione e limiti di gestione

Di seguito è riportato un esempio illustrativo del funzionamento dello smoothing per un'operazione in background che ha utilizzato 1 CUHr (l'utilizzo era equivalente a 1 CU per 1 ora). Le operazioni in background vengono ottimizzate nell'arco di 24 ore. Il contributo di un'operazione in background in un qualsiasi momento temporale è # CUHrs per l'operazione / # di CUHrs a livello di SKU. Per un F2, questo lavoro contribuirebbe con 1 CUHr / 48CUhrs = ~2.1% a ciascun momento temporale. L'impatto sui limiti di regolazione di 10 minuti e 60 minuti è di circa 2,1%.

Ecco i dettagli che supportano l'esempio:

1 CUHr = 3.600 UR (1 CU * 60 minuti all'ora * 60 secondi al minuto)

Ogni punto di tempo è lungo 30 secondi. In 24 ore sono presenti 2.880 punti di tempo (24 ore * 60 minuti * 2 punti di tempo al minuto).

Poiché le 3600 CUs vengono uniformati in 24 ore, il processo contribuisce a 3.600 CUs/2.880 timepoint per ogni timepoint di 30 secondi. Contribuisce quindi con 1,25 CUs per istante.

La percentuale di limitazione di 10 minuti si basa sui CUs totali disponibili nei successivi 10 minuti di attività della capacità.

Una capacità F2 ha 2 CU per ogni secondo (o 2 CU). In ogni punto di tempo, un F2 ha 2 unità di elaborazione * 30 secondi = 60 unità di elaborazione.

Il contributo del processo in background a qualsiasi singolo punto temporale è di 1,25 CU/60 CU = ~2,1% di un singolo punto temporale.

In 10 minuti, F2 ha 2 CU * 60 secondi * 10 minuti = 1.200 UNITÀ di calcolo.

La parte del processo in background che è stata smussata nei successivi 10 minuti di capacità è di 1,25 CPU * 2 punti di tempo al minuto * 10 minuti = 25 UNITÀ di calcolo.

Pertanto, la percentuale di limitazione di 10 minuti è di 25 CPU / 1.200 UR = ~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 utilizzato più UNITÀ di calcolo rispetto a quelle disponibili nell'intervallo di tempo di 10 minuti successivo (ha utilizzato sei volte la quantità), la capacità F2 non viene limitata perché le UNITÀ di calcolo totali vengono uniformate in più 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 usano una capacità maggiore rispetto a quella supportata dallo SKU in un singolo punto di tempo, viene calcolato un sovraccarico . Le eccedenze vengono calcolate dopo l'applicazione dello smoothing. Se sono presenti eccedenze che superano la finestra di limitazione consentita di 10 minuti, diventano CU di trasporto.

La protezione dell'eccedenza garantisce che la capacità non venga ridotta fino a quando la finestra di regolazione di 10 minuti non è piena. È progettato per ridurre la frequenza dei ritardi interattivi dovuti a picchi temporanei di utilizzo.

Le CUs riportate vengono applicate a ogni momento successivo. Se un punto di tempo non è pieno, le UR inutilizzate riducono l'importo delle UR di trasporto. La riduzione viene definita 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 delle capacità possono configurare avvisi di posta elettronica per ricevere una notifica quando una capacità consuma 100% delle risorse CU di cui è stato effettuato il provisioning. 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. Quando si utilizzano gli SKU F, è possibile aumentare o ridurre manualmente le dimensioni dello SKU nelle impostazioni di amministrazione in qualsiasi momento, per risolvere eventuali problemi di strozzatura quando necessario.

Come capire che si sta verificando la limitazione della capacità

Quando una capacità rifiuta le richieste, gli utenti visualizzano codici di errore e testo di errore specifici:

1. Codice di stato CapacityLimitExceeded
2. Messaggio di errore Your organization's Fabric compute capacity has excceded its limits. Try again later.
3. Messaggio di errore Cannot load model due to reaching capacity limits

Nota

Rallentamento delle prestazioni se spesso dovuto alla progettazione di un elemento. 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.

1. La tabella Eventi di sistema nella pagina Calcolo mostra la cronologia degli eventi di regolazione.
2. 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 la limitazione più velocemente, è possibile usare le strategie elencate di seguito.

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.
• Sospendi e poi riprendi le tue capacità. 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.

Quando si usano le funzionalità SKU P, per arrestare il throttling:

• Abilitare la scalabilità automatica per la capacità P.

Le operazioni in anteprima non sono limitate

La limitazione influisce solo sulle operazioni richieste dopo che la capacità inizia a limitare. Tutte le operazioni, incluse quelle a esecuzione prolungata inviate prima dell'inizio della limitazione, possono essere eseguite fino al completamento. Questo comportamento garantisce che le operazioni vengano 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 il modulo dati OneLake per fornire il risultato della query. Ognuna di queste richieste costituisce una catena.

Quando è presente una catena di chiamate, esiste un rischio di limitazione composta, ovvero quando la limitazione viene applicata più volte alla stessa richiesta. Fabric ha una protezione di limitazione composta incorporata che riduce la probabilità che si verifichi una limitazione composta. I carichi di lavoro possono acconsentire esplicitamente all'uso di questa protezione.

Quando i carichi di lavoro supportano la protezione della limitazione combinata, una richiesta viene limitata una sola volta per ogni risorsa 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 si basa su più di una capacità, ogni capacità applica la limitazione una volta per la prima richiesta ricevuta nella catena.

Le esperienze del carico di lavoro seguenti supportano la limitazione composta:

• Modelli semantici che si connettono ad altri modelli semantici tramite Direct Query.
• 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 limitazione indicate in precedenza, esistono alcune eccezioni.

Ad esempio, i flussi di eventi di Fabric hanno molte operazioni che possono essere eseguite per anni dopo l'avvio. La limitazione delle nuove operazioni eventstream non avrebbe senso, quindi la quantità di risorse cu allocate per mantenere aperto il flusso viene ridotta fino a quando la capacità non è di nuovo in buona posizione.

Un'altra eccezione è l'intelligenza in tempo reale, che non sarebbe in tempo reale se le operazioni fossero ritardate 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 gli utenti possano continuare a godere di prestazioni in tempo reale anche durante periodi di domanda elevata.

Analogamente, quasi tutte le operazioni nella categoria Warehouse vengono segnalate come background per sfruttare il lisciamento di 24 ore dell'attività e consentire i modelli di utilizzo più flessibili. La classificazione di tutti i data warehousing come background impedisce che i picchi di utilizzo di CU attivino troppo rapidamente la limitazione delle richieste. Alcune richieste potrebbero attivare una catena di operazioni regolate in modo diverso. Quando un'operazione interattiva avvia una catena che include un'operazione in background, quest'ultima può essere soggetta alla limitazione al pari di un'operazione interattiva.

Classificazioni interattive e in background per la limitazione e il lisciamento

Alcuni amministratori potrebbero notare che le operazioni vengono talvolta classificate come interattive e lisciate come background, o viceversa. Questa distinzione si verifica perché i sistemi di limitazione di Fabric devono applicare regole di limitazione prima che una richiesta inizi l'esecuzione.

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 passa alla classificazione delle operazioni come background, nel miglior interesse dell'utente.

Monitorare le eccedenze e le operazioni rifiutate

È possibile verificare se la capacità è sovraccaricata esaminando il grafico Utilizzonell'app Metriche della capacità di Microsoft Fabric. Un picco che supera la riga indica un sovraccarico. Per analizzare ulteriormente l'eccedenza, approfondisci nella pagina dei punti temporali. È quindi possibile esaminare sia le operazioni interattive che quelle in background e verificare quali sono state responsabili delle eccedenze.

Poiché l'utilizzo superiore al 100% non implica automaticamente la limitazione, è necessario usare ilGrafico della Limitazione durante la valutazione delle eccedenze. Da qui è possibile aprire una tabella che mostri i minuti per il burndown, un grafico con la percentuale di aggiunta, burndown e cumulativa, 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 qualsiasi sovrautilizzo della capacità, tra cui trasporto, cumulativo e burndown dei dati di utilizzo, passare alla scheda Eccedenze . È possibile modificare la scala visiva delle eccedenze per visualizzare 10 minuti, 60 minuti e 24 ore.

Il drill-down dell'app Microsoft Fabric Capacity Metrics consente agli amministratori di visualizzare le operazioni rifiutate durante un evento di limitazione. Visto che non sono mai state autorizzate a iniziare, le informazioni disponibili per queste operazioni sono limitate. L'amministratore può visualizzare il prodotto, l'utente, l'ID dell’operazione e l'ora di invio della richiesta. Quando una richiesta viene rifiutata, gli utenti finali ricevono un messaggio di errore nel quale viene loro chiesto di riprovare più tardi.

Calcolo fatturabile e non fatturabile

Quando si esamina l'utilizzo della capacità nell'app per le metriche della capacità, alcune operazioni sono fatturabili e altre non fatturabili. Solo le operazioni fatturabili sono incluse nei calcoli di limitazione. Le funzionalità di anteprima possono generare operazioni non fatturabili. Usare operazioni non fatturabili per pianificare in anticipo in modo che la capacità venga ridimensionata correttamente quando queste funzionalità di anteprima diventano fatturabili.

Contenuto correlato

• Per monitorare le capacità di Fabric, installare l'app Microsoft Fabric Capacity Metrics.
• Come ridimensionare la capacità.