Begränsningsprincipen för infrastrukturresurser

  • Artikel

Begränsning sker när en klients kapacitet förbrukar fler kapacitetsresurser än den har köpt. För mycket begränsning kan leda till en försämrad slutanvändarupplevelse. En Fabric-klientorganisation kan skapa flera kapaciteter och tilldela arbetsytor till en viss kapacitet för fakturering och storleksändring.

Begränsning tillämpas på kapacitetsnivå, vilket innebär att även om en kapacitet, eller en uppsättning arbetsytor, kan ha sämre prestanda på grund av överbelastning, kan andra kapaciteter fortsätta att köras normalt. I fall där funktioner som OneLake-artefakter produceras i en kapacitet och förbrukas av en annan, avgör begränsningstillståndet för den förbrukande kapaciteten om anrop till artefakten begränsas.

Balans mellan prestanda och tillförlitlighet

Fabric är utformat för att leverera blixtsnabba prestanda till sina kunder genom att ge driften åtkomst till fler CU-resurser (kapacitetsenheter) än vad som allokeras till kapaciteten. Uppgifter som kan ta flera minuter att slutföra på andra plattformar kan slutföras på bara några sekunder i Infrastrukturresurser. För att undvika att straffa användare när driftbelastningen ökar jämnar Fabric ut eller medelvärder CU-användningen av en åtgärd under minst 5 minuter, och ännu längre för begäranden med hög CU men kort körning. Det här beteendet säkerställer att du kan få konsekvent snabba prestanda utan begränsning.

För bakgrundsåtgärder som har långa körningstider och förbrukar tunga CU-belastningar jämnar Fabric ut sin CU-användning under en 24-timmarsperiod. Utjämning eliminerar behovet av att dataforskare och databasadministratörer ägnar tid åt att skapa jobbscheman för att sprida CU-belastningen över dagen för att förhindra att konton fryser. Med 24-timmars CU-utjämning kan schemalagda jobb köras samtidigt utan att orsaka några toppar när som helst under dagen, och du kan få konsekvent snabba prestanda utan att slösa tid på att hantera jobbscheman.

Åtgärder under flygning begränsas inte

När en kapacitet går in i ett begränsat tillstånd påverkar den bara åtgärder som begärs efter att kapaciteten har börjat begränsas. Alla åtgärder, inklusive långvariga åtgärder som skickades innan begränsningen började, tillåts köras till slutförande. Det här beteendet ger dig en försäkran om att åtgärderna har slutförts, även under CU-överspänningar.

Begränsningsutlösare och begränsningssteg

Efter utjämningen kan vissa konton fortfarande uppleva toppar i CU-användningen under de högsta rapporteringstiderna. För att hjälpa till att hantera dessa toppar kan administratörer konfigurera e-postaviseringar som ska meddelas när en kapacitet förbrukar 100 % av dess etablerade CU. Det här mönstret är en indikation på att kapaciteten kan dra nytta av belastningsutjämning, och administratören bör överväga att öka SKU-storleken. Observera att för F SKU:er kan du öka och minska dem manuellt när som helst i administratörsinställningarna. Men även om en kapacitet fungerar med sin fulla CU-potential tillämpar Fabric inte begränsning. Detta säkerställer att användarna har konsekvent snabba prestanda utan att uppleva några störningar.

Den första begränsningsfasen börjar när en kapacitet har förbrukat alla sina tillgängliga CU-resurser under de kommande 10 minuterna. Om du till exempel har köpt 10 enheter CU och sedan förbrukat 50 enheter per minut skapar du en överföring framåt på 40 enheter per minut. Efter två och en halv minut skulle du ha ackumulerat en överföring framåt på 100 enheter, lånade från framtida fönster. Nu när kapaciteten redan har förbrukat all kapacitet under de kommande 10 minuterna initierar Fabric sin första begränsningsnivå och alla nya interaktiva åtgärder fördröjs med 20 sekunder vid sändning. Om överföringsförflyttningen når en hel timme avvisas interaktiva begäranden, men schemalagda bakgrundsåtgärder fortsätter att köras. Om kapaciteten ackumulerar hela 24 timmars transport framåt fryses hela kapaciteten tills överföringsbefordrningen har betalats ut.

Framtida utjämnad förbrukning

Kommentar

Microsoft försöker förbättra kundens flexibilitet när det gäller att använda tjänsten, samtidigt som behovet av att hantera kundens kapacitetsanvändning balanseras. Därför kan Microsoft ändra eller uppdatera begränsningsprincipen för infrastrukturresurser.

Användning Principgränser Påverkan på plattformspolicy
Användning <= 10 minuter Skydd mot överförbrukning Jobb kan förbruka 10 minuters framtida kapacitetsanvändning utan begränsning.
10 minuter < Användning <= 60 minuter Interaktiv fördröjning Användar begärda interaktiva jobb fördröjs 20 sekunder vid sändning.
60 minuter < Användning <= 24 timmar Interaktivt avvisande Användar begärda interaktiva jobb avvisas.
Användning > 24 timmar Bakgrundsavslag Alla begäranden avvisas.

Kapacitetsminskning för överföring av kapacitet

När en kapacitet har inaktiv kapacitet betalar systemet ned överföringsnivåerna.

Om du har 100 CU minuter och en överföring framåt på 200 CU minuter, och du inte har några åtgärder igång, tar det två minuter för dig att betala av din överföring framåt. I det här exemplet begränsas inte systemet eftersom det finns 2 minuters överföring framåt. Begränsningsfördröjningar börjar inte förrän det är 10 minuters överföring framåt.

Om du behöver betala ned din överföring snabbare kan du öka SKU-storleken tillfälligt för att generera mer inaktiv kapacitet som tillämpas på din överföring framåt.

Begränsningsbeteendet är specifikt för Infrastrukturresurser

De flesta Fabric-produkter följer de tidigare nämnda begränsningsreglerna, men det finns vissa undantag.

Till exempel har Fabric-händelseströmmar många åtgärder som kan köras i flera år när de har startats. Det skulle inte vara meningsfullt att begränsa nya händelseströmåtgärder, så i stället minskas mängden CU som allokerats för att hålla strömmen öppen tills kapaciteten är i gott skick igen.

Ett annat undantag är Realtidsanalys, som inte skulle vara realtid om åtgärderna försenades med 20 sekunder. Därför ignorerar Realtidsanalys den första fasen av begränsningen med 20 sekunders fördröjningar vid 10 minuters överföring framåt och väntar tills avvisningsfasen vid 60 minuters överföring framåt för att påbörja begränsningen. Det här beteendet säkerställer att användarna kan fortsätta att få prestanda i realtid även under perioder med hög efterfrågan.

På samma sätt rapporteras nästan alla åtgärder i kategorin Lager som bakgrund för att dra nytta av 24-timmars utjämning av aktiviteten för att möjliggöra de mest flexibla användningsmönstren. Om du klassificerar alla datalager som bakgrund förhindrar du att toppar i CU-användningen utlöser begränsningar för snabbt. Vissa begäranden kan utlösa en sträng med åtgärder som begränsas på olika sätt. Detta kan göra att en bakgrundsåtgärd blir föremål för begränsning som en interaktiv åtgärd.

Interaktiva klassificeringar och bakgrundsklassificeringar för begränsning och utjämning

Vissa administratörer kanske märker att åtgärder ibland klassificeras som interaktiva och utjämnade som bakgrund, eller vice versa. Den här skillnaden sker eftersom Infrastrukturresursers begränsningssystem måste tillämpa begränsningsregler innan en begäran börjar köras. Utjämning sker när jobbet har börjat köras och CU-förbrukningen kan mätas.

Begränsningssystem försöker kategorisera åtgärder korrekt när de skickas, men ibland kan en åtgärds klassificering ändras när begränsningen har tillämpats. När åtgärden börjar köras blir mer detaljerad information om begäran tillgänglig. I tvetydiga scenarier försöker begränsningssystem fela på sidan av att klassificera åtgärder som bakgrund, vilket ligger i användarens intresse.

Spåra avvisade åtgärder

Med appgranskningen för Microsoft Fabric Capacity Metrics kan administratörer se åtgärder som avvisades under en begränsningshändelse. Det finns begränsad information om dessa åtgärder eftersom de aldrig tilläts starta. Administratören kan se produkten, användaren, åtgärds-ID:t och tiden då begäran skickades. Slutanvändarna får ett felmeddelande när en begäran avvisas som ber dem att försöka igen senare.

Relaterat innehåll