Politica di Fabric sulla limitazione.

La limitazione si verifica quando la capacità di un tenant utilizza più risorse di capacità rispetto a quelle acquistate. 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 veloci ai propri clienti consentendo alle operazioni di accedere a più risorse di unità di capacità (CU) rispetto a quelle allocate alla capacità. Le attività che in altre piattaforme potrebbero richiedere alcuni minuti per il completamento, in Fabric possono essere completate in pochi secondi. Per evitare di penalizzare gli utenti durante l'aumento dei carichi operativi, Fabric uniforma o raggiunge la media dell'utilizzo di CU di un'operazione in un minimo di cinque minuti e anche più a lungo per l'utilizzo elevato della CU, ma con richieste di runtime brevi. Questo comportamento garantisce prestazioni costantemente veloci senza riscontrare limitazioni.

Per le operazioni in background con runtime lunghi e che utilizzano carichi di CU pesanti, Fabric consente di uniformare l'utilizzo delle CU in un periodo di 24 ore. Grazie al lisciamento, gli scienziati dei dati e gli amministratori di database non avranno bisogno di dedicare tempo alla creazione di pianificazioni dei processi per distribuire il carico CU nel corso della giornata e impedire dunque il blocco degli account. Con un lisciamento di CU di 24 ore, i processi pianificati possono essere eseguiti tutti contemporaneamente, senza causare picchi in qualsiasi momento del giorno, e sarà possibile godere di prestazioni costantemente veloci senza sprecare tempo nella gestione delle pianificazioni dei processi.

Le operazioni in anteprima non sono limitate

Quando una capacità entra in uno stato limitato, influisce solo sulle operazioni richieste dopo l'avvio della limitazione della capacità. 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.

Trigger e fasi della limitazione

Dopo il lisciamento, alcuni account potrebbero ancora riscontrare picchi di utilizzo delle CU durante i periodi di picco di reporting. Per gestire questi picchi, gli amministratori possono configurare avvisi di posta elettronica per ricevere una notifica quando una capacità consuma il 100% delle risorse CU di cui è stato effettuato il provisioning. Questo modello indica che la capacità può trarre vantaggio dal bilanciamento del carico e che l'amministratore deve prendere in considerazione l'aumento delle dimensioni dello SKU. È importante notare che per gli SKU F, è possibile aumentarli e ridurli manualmente in qualsiasi momento nelle impostazioni di amministrazione. Tuttavia, anche quando una capacità funziona al massimo del potenziale CU, Fabric non applica la limitazione. Questo comportamento garantisce che gli utenti abbiano prestazioni costantemente veloci senza subire interruzioni.

La prima fase della limitazione inizia quando una capacità ha utilizzato tutte le risorse CU disponibili per i 10 minuti successivi. Ad esempio, se sono state acquistate 10 unità di capacità e quindi sono state utilizzate 50 unità al minuto, si creerà un trasporto di 40 unità al minuto. Dopo due minuti e mezzo, si sarà accumulato un trasporto di 100 unità, preso in prestito dalle finestre future. A questo punto, quando tutta la capacità per i prossimi 10 minuti è già esaurita, Fabric avvia il primo livello di limitazione e tutte le nuove operazioni interattive vengono ritardate di 20 secondi dall'invio. Se il trasporto raggiunge un'ora intera, le richieste interattive vengono rifiutate, ma le operazioni in background pianificate continuano a essere eseguite. Se la capacità accumula un totale di 24 ore di trasporto, l'intera capacità viene bloccata fino a quando il trasporto non viene ripagato.

Consumo lisciato futuro

Riduzione dell'utilizzo della capacità di trasporto

Ogni volta che una capacità ha capacità inattiva, il sistema paga in anticipo i livelli di trasporto.

Se si hanno 100 minuti di CU e un trasporto di 200 minuti di CU, e non c’è alcuna operazione in esecuzione, ci vorranno due minuti per ripagare il carico di trasporto. In questo esempio, il sistema non viene limitato, in quanto ci sono due minuti di trasporto. I ritardi di limitazione non inizieranno fino a quando non si accumulano 10 minuti di trasporto.

Se è necessario pagare il trasporto più velocemente, è possibile aumentare temporaneamente le dimensioni dello SKU per generare una capacità di inattività maggiore applicata al trasporto.

Il comportamento della limitazione è specifico di 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. Visto che non avrebbe senso limitare le nuove operazioni del flusso di eventi, 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, l'intelligenza in tempo reale ignora la prima fase di limitazione con ritardi di 20 secondi a 10 minuti di trasporto e attende fino alla fase di rifiuto a 60 minuti di trasporto 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 stringa di operazioni limitate in modo diverso. Ciò può rendere un'operazione in background soggetta alla limitazione in quanto operazione interattiva.

Classificazioni interattive e in background per la limitazione e il lisciamento

Microsoft Fabric divide le operazioni in due tipi, interattive e in background. Nelle operazioni di Fabric è possibile scoprire cosa sono e come si distinguono.

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 lisciamento si verifica dopo l'avvio dell'esecuzione del processo e la possibilità di misurare il consumo di CU.

I sistemi di limitazione tentano di classificare accuratamente le operazioni all'invio, ma talvolta la classificazione di un'operazione potrebbe cambiare dopo l'applicazione della limitazione. Quando l'operazione inizia a essere eseguita, si avrà la possibilità di accedere a maggiori informazioni sulla richiesta. In scenari ambigui, i sistemi di limitazione tentano di eseguire errori in favore della classificazione delle operazioni in background, in quanto maggiormente favorevole agli interessi dell'utente.

Monitorare le eccedenze e le operazioni rifiutate

È possibile verificare se la capacità sia in overload esaminando il grafico di Utilizzo nell'app Microsoft Fabric Capacity Metrics. Un picco che supera la riga indica un overload. Per analizzare ulteriormente l'overload, eseguire il drill-through alla pagina punto nel tempo. È quindi possibile esaminare sia le operazioni interattive che quelle in background e verificare quali siano state responsabili dell'overload della capacità. È anche possibile determinare quando si siano verificati gli eventi di overload.

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.

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 trasporto tiene conto solo delle operazioni fatturabili.

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.

Azioni che è possibile eseguire per il ripristino da situazioni di overload

Quando la capacità è limitata fino a essere bloccata, gli utenti ricevono un errore nel caso in cui debbano usare le risorse di calcolo di Fabric. Ad esempio, l'errore potrebbe dire: Impossibile caricare il modello a causa del raggiungimento dei limiti di capacità. In questi casi, è possibile usare queste strategie per far riprendere la capacità dallo stato di bloccata.

• Attendere che lo stato dell'overload sia finito prima di inviare nuove richieste.
• Aggiornare lo SKU di una capacità F.
• Sospendere/riprendere una capacità F.
• Ridimensionare automaticamente una capacità P.
• Togliere dalla capacità la priorità meno importante o l'eccedenza delle aree di lavoro.

Contenuto correlato

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