Fabric-begrænsningspolitikken

Begrænsning forekommer, når handlinger bruger flere beregningsenheder sekunder (CU'er), end kapacitets-SKU'en tillader. For meget begrænsning kan resultere i en forringet slutbrugeroplevelse. En Microsoft Fabric-lejer kan oprette flere kapaciteter og tildele arbejdsområder til en bestemt kapacitet til fakturering og størrelse.

Begrænsning anvendes på kapacitetsniveau, hvilket betyder, at mens én kapacitet eller et sæt arbejdsområder kan opleve reduceret ydeevne på grund af overbelastning, kan andre kapaciteter fortsætte med at køre normalt. I tilfælde, hvor funktioner som OneLake-artefakter produceres i én kapacitet og forbruges af en anden, bestemmer forbrugskapacitetens begrænsningstilstand, om kald til artefaktet begrænses.

Balance mellem ydeevne og pålidelighed

Fabric er designet til at levere hurtig ydeevne til kunderne. Opgaver, der kan tage flere minutter at udføre på andre platforme, kan afsluttes på få sekunder på Fabric. Store handlinger kan køre når som helst på dagen, uden at der er behov for omhyggelig planlægning, fordi beregningen for disse handlinger er fordelt over en længere periode uden at gøre handlingen langsommere. Fabric gør det muligt ved hjælp af indbygget sprængning og udjævning. De gør det muligt for kapaciteter at administrere sig selv og selvreparerende, når midlertidige stigninger i forbruget ellers ville medføre, at andre systemer mislykkes eller bremses.

Sprængfyldt

For at sikre hurtig ydeevne bruger Fabric bursting til at lade handlinger køre så hurtigt som muligt. Bursting gør det muligt for handlinger midlertidigt at bruge mere beregning end den klargjorte beregning for kapacitets-SKU'en. På grund af sprængning får brugerne hurtigt resultater uden at vente. Sprængning gør det også muligt for en mindre kapacitet at køre større handlinger, der normalt kræver en dyrere kapacitet.

Udjævning

Hvis du vil undgå at straffe brugerne, når driften drager fordel af sprængning, glatter Fabric eller gennemsnit, cu-brugen af en handling over en længere tidsramme. Denne funktionsmåde sikrer, at brugerne kan få en ensartet hurtig ydeevne uden at opleve begrænsning.

Udjævning distribuerer forbrugt CU-forbrug i forhold til fremtidige tidspunkter. Tidspunkter i Fabric er 30 sekunder lange. Der er 2.880 tidspunkter inden for de næste 24 timer. Fabric administrerer automatisk mængden af forbrug af CU'er i hvert tidspunkt.

En handlings udnyttelsestype bestemmer antallet af tidspunkter, der bruges til udjævning. Få mere at vide om Fabric-handlinger.

• Interaktive handlinger udjævnes over mindst fem minutter og op til 64 minutter, afhængigt af hvor meget CU-forbrug de forbruger.
• Baggrundshandlinger udjævnes over en 24-timers periode, fordi de typisk har lange kørselstider og stort CU-forbrug.

På grund af udjævning gælder kun en del af CU-forbruget for en handling for et individuelt tidspunkt, hvilket reducerer begrænsningen generelt. Udjævnet cu-forbrug akkumuleres, når handlinger køres. Udjævnet forbrug betales af den fremtidige kapacitet, som er de CU'er, der er tilgængelige i fremtidige tidspunkter, fordi kapaciteten kører løbende.

Sprængning og udjævning arbejder sammen for at gøre det nemmere for kapacitetsbrugere at udføre deres arbejde. Brugerne bruger f.eks. typisk tid på at planlægge job og sprede dem ud på tværs af dagen. Med udjævning udjævnes beregningsomkostningerne for baggrundsjob over 24 timer. Det betyder, at planlagte job kan køre samtidigt uden at forårsage stigninger, der ellers ville forhindre job i at starte. Samtidig kan brugerne få en ensartet hurtig ydeevne uden at vente på, at langsomme job fuldføres eller spilder tid på administration af jobplaner.

Bemærk

Sprængning og udjævning understøttes ikke, når en kapacitetsadministrator har aktiveret automatisk skalering af fakturering for Spark. I dette scenarie fungerer Spark-forbruget i en pay-as-You-Go-tilstand, og begreberne sprængning og udjævning gælder ikke.

Throttle-udløsere og throttle-faser

Selvom kapaciteter har indbygget udjævning, der reducerer virkningen af stigninger i forbruget, er det stadig muligt at overbelaste en kapacitet ved at køre for mange handlinger.

Kapaciteten begrænser automatisk nye handlinger, når den overbelastes. Begrænsning sker i progressive trin for at minimere indvirkningen på vigtige opgaver, f.eks. dataopdateringer.

Selv når en kapacitet kører over 100% udnyttelse, anvender Fabric ikke øjeblikkelig begrænsning. Kapaciteten giver i stedet beskyttelse mod overforbrug , der gør det muligt at forbruge 10 minutters fremtidig kapacitet uden begrænsning. Denne funktionsmåde giver en begrænset indbygget beskyttelse mod overspænding, samtidig med at brugerne får en ensartet hurtig ydeevne uden afbrydelser.

Begrænsningen starter, når en kapacitet bruger alle sine CU-ressourcer i de næste 10 minutter. Den første fase af begrænsningen anvender 20 sekunders forsinkelser på nye interaktive handlinger. Den anden fase af begrænsningen afviser nye interaktive handlinger, når en kapacitet bruger alle sine CU-ressourcer i den næste time. I denne fase har handlinger i baggrunden tilladelse til at starte og køre. Den tredje fase af begrænsningsafvisningen af alle nye anmodninger, interaktiv og baggrund, når kapaciteten bruger alle sine tilgængelige CU-ressourcer i de næste 24 timer. Kapaciteten fortsætter med at begrænse anmodninger, indtil den forbrugte CU betales.

Bemærk

Microsoft forsøger at forbedre kundefleksibiliteten i forbindelse med brugen af tjenesten, samtidig med at behovet for at administrere forbrug af kundekapacitet opvejes. Derfor kan Microsoft ændre eller opdatere Fabric-begrænsningspolitikken.

Tabellen opsummerer begrænsningsudløsere og -faser.

Brug	Politikgrænser	Effekt af platformspolitikoplevelse
Forbrug <= 10 minutter	Beskyttelse mod overage	Job kan forbruge 10 minutters fremtidig kapacitetsanvendelse uden begrænsning.
10 minutter < forbrug <= 60 minutter	Interaktiv forsinkelse	Brugeropsøgte interaktive job forsinkes 20 sekunder ved indsendelse.
60 minutter < forbrug <= 24 timer	Interaktiv afvisning	Brugeropsøgte interaktive job afvises.
Forbrug > 24 timer	Afvisning i baggrunden	Alle anmodninger afvises.

Eksempel på grænser for udjævning og begrænsning

Her er et illustrerende eksempel på, hvordan udjævning fungerer for én baggrundshandling, der brugte 1 CU/t (dens forbrug svarede til 1 CU i 1 time). Handlinger i baggrunden udjævnes over 24 timer. En baggrundshandlings bidrag på et hvilket som helst tidspunkt er # CUHrs for handlingen /# af CUHrs på SKU-niveauet. For en F2 vil dette job bidrage med 1 CU/48CUhrs = ~2,1% til hvert tidspunkt. Indvirkningen på begrænsningsgrænserne på 10 minutter og 60 minutter er ca. 2,1%.

Her er de detaljer, der understøtter eksemplet:

1 CU Pr. time = 3.600 CU'er (1 CU * 60 minutter i timen * 60 sekunder pr. minut)

Hvert klokkeslæt er 30 sekunder langt. På 24 timer er der 2.880 tidspunkter (24 timer * 60 minutter * 2 timepunkter pr. minut).

Da de 3600 CU'er er udjævnet over 24 timer, bidrager jobbet med 3.600 CU'er/2.880 timepoint til hvert 30. sekund. Så det bidrager med 1,25 CU'er pr. timepoint.

Begrænsningsprocenten på 10 minutter er baseret på den samlede tilgængelige CUs i de næste 10 minutter af kapacitetens oppetid.

En F2-kapacitet har 2 CU for hvert sekund (eller 2 CU'er). I hvert tidspunkt har en F2 2 CUs * 30 sekunder = 60 CUs beregning.

Baggrundsjobbets bidrag til et individuelt tidspunkt er 1,25 CU'er/60 CU'er = ~2.1% af et individuelt klokkeslæt.

På 10 minutter har F2 2 CU * 60 sekunder * 10 minutter = 1.200 CUs beregning.

Den del af baggrundsjobbet, der blev udjævnet i de næste 10 minutter af kapaciteten, er 1,25 CU'er * 2 timepunkter pr. minut * 10 minutter = 25 CU'er.

Begrænsningsprocenten på 10 minutter er derfor 25 CU'er /1.200 CUs = ~2,1%.

På samme måde er påvirkningen af baggrundsjobbet på 60 minutter også ca. 2,1%.

Selvom baggrundshandlingen brugte flere CPU'er, end der er tilgængelige inden for det næste 10-minutters tidsrum (den brugte seks gange mængden), begrænses F2-kapaciteten ikke, fordi de samlede CUs udjævnes over 24 timer. På grund af udjævning gælder kun en lille del af de anvendte CU'er for et hvilket som helst individuelt tidspunkt.

Overskridelser, fremførsel og nedbrænding

Når handlinger bruger mere kapacitet, end SKU'en understøtter på et enkelt tidspunkt, beregnes der en overforbrug . Overages beregnes, når udjævning er anvendt. Hvis der er overskridelser, der overstiger det tilladte 10-minutters begrænsningsvindue, bliver de carryforward CUs.

Beskyttelse mod overbesættelse sikrer, at kapaciteten ikke begrænses, før 10-minutters begrænsningsvinduet er fuldt. Det er designet til at reducere hyppigheden af interaktive forsinkelser på grund af midlertidige stigninger i udnyttelsen.

De bevillinger, der fremføres, anvendes på hvert efterfølgende tidspunkt. Hvis et tidspunkt ikke er fuldt, reducerer de ubrugte CU'er mængden af fremførsels-C'er. Reduktionen kaldes burndown.

Begrænsning af håndhævelse fortsætter, indtil ubrugt kapacitet betaler sig for alle fremførsels-CU'er.

Overvågning af kapaciteter til begrænsning

Kapacitetsadministratorer kan konfigurere mailbeskeder for at få besked, når en kapacitet bruger 100% af sine klargjorte CU-ressourcer. Administratorer kan også bruge appen med kapacitetsmålepunkter til at gennemse begrænsningsniveauer for deres kapacitet.

Tilpasning og optimering af en kapacitet

Konsekvent høje begrænsningsniveauer angiver behovet for belastningsjustering på tværs af flere kapaciteter eller øge kapacitetens SKU-størrelse. Når du bruger F-SKU'er, kan du til enhver tid manuelt øge og reducere SKU-størrelsen i administratorindstillingerne, hvilket giver dig mulighed for at løse begrænsningen, når det er nødvendigt.

Sådan fortæller du, at kapacitetsbegrænsningen forekommer

Når en kapacitet afviser anmodninger, får brugerne vist specifikke fejlkoder og fejltekst:

1. Statuskode CapacityLimitExceeded
2. Fejlmeddelelse Your organization's Fabric compute capacity has excceded its limits. Try again later.
3. Fejlmeddelelse Cannot load model due to reaching capacity limits

Bemærk

Langsom ydeevne, hvis det ofte skyldes designet af et element. Kun nogle gange er ydeevnen langsom på grund af kapacitetsbegrænsning.

Når en kapacitet er overbelastet, kan en kapacitetsadministrator bruge appen Fabric capacity metrics til at bekræfte begrænsningen.

1. Tabellen Systemhændelser på siden Compute viser historikken for begrænsningshændelser.
2. Throttling-diagrammerne på siden Compute vises, når det udjævnede forbrug overskrider en af begrænsningsgrænserne.

Sådan stopper du begrænsningen, når den opstår

Kapaciteter er selvreparerende, så du kan altid vente, indtil overbelastningstilstanden er forbi, før du sender nye anmodninger.

Hvis du vil stoppe begrænsningen hurtigere, kan du dog bruge de strategier, der er angivet nedenfor.

Når du bruger F SKU-kapaciteter, skal du stoppe begrænsningen:

• Forøg sku'en midlertidigt. Ved at øge din SKU kan du brænde frem hurtigere, fordi hvert timepoint har mere inaktiv kapacitet.
• Afbryd midlertidigt, og genoptag derefter din kapacitet. Hvis du afbryder en kapacitet midlertidigt, medfører det en faktureringshændelse for det akkumulerede fremtidige kapacitetsforbrug. Når en kapacitet starter eller genoptages, har den ingen fremtidige kapacitetsforbrug, så den kan acceptere nye handlinger med det samme.

Når du bruger P SKU-kapaciteter, skal du stoppe begrænsningen:

• Aktivér Automatisk skalering for P-kapaciteten.

In-flight operationer er ikke begrænset

Begrænsning påvirker kun de handlinger, der anmodes om, når kapaciteten starter begrænsningen. Alle handlinger, herunder langvarige handlinger, der blev sendt, før begrænsningen begyndte, har tilladelse til at køre til fuldførelse. Denne funktionsmåde giver dig sikkerhed for, at handlingerne er fuldført, selv under overspændinger i CU-forbrug.

Beskyttelse mod sammensat begrænsning

I Fabric udløser én handling ofte andre elementer eller arbejdsbelastninger, der skal fuldføres. Der er mange eksempler, men en typisk er visning af en rapport. Hver visualisering i rapporten kører en forespørgsel i forhold til en underliggende semantisk model. Den semantiske model kan også læse dataformularen OneLake for at levere forespørgselsresultatet. Hver af disse anmodninger udgør en kæde.

Når der er en kæde af opkald, er der risiko for sammensat begrænsning, hvilket er, når begrænsning anvendes mere end én gang på den samme anmodning. Fabric har en indbygget forbindelsesbegrænsningsbeskyttelse, der reducerer sandsynligheden for, at der forekommer en sammensat begrænsning. Arbejdsbelastninger kan vælge at bruge denne beskyttelse.

Når arbejdsbelastninger understøtter sammensat begrænsningsbeskyttelse, begrænses en anmodning kun én gang for hver kapacitet, der deltager i kæden. Begrænsningsbeslutningen opstår, når anmodningen starter og gælder for alle handlinger i kæden.

Hvis en kæde er afhængig af mere end én kapacitet, gennemtvinger hver kapacitet begrænsningen én gang for den første anmodning, den modtager i kæden.

Følgende arbejdsbelastningsoplevelser understøtter sammensat begrænsning:

• Semantiske modeller, der opretter forbindelse til andre semantiske modeller ved hjælp af Direct Query.
• DAX-forespørgsler fra sideinddelte rapporter til semantiske modeller.

Begrænsningsfunktionsmåden er specifik for Fabric-arbejdsbelastninger

Selvom de fleste Fabric-produkter følger de tidligere nævnte begrænsningsregler, er der nogle undtagelser.

Fabric-eventstreams har f.eks. mange handlinger, der kan køre i årevis, når de er startet. Det ville ikke give mening at begrænse nye eventstream-operationer, så i stedet reduceres mængden af CU-ressourcer, der er allokeret til at holde strømmen åben, indtil kapaciteten er i god stand igen.

En anden undtagelse er Realtidsintelligens, som ikke ville være i realtid, hvis handlingerne blev forsinket med 20 sekunder. Derfor anvender Real-Time Intelligence ikke den første fase af begrænsningen med 20 sekunders forsinkelser med 10 minutters fremtidig kapacitet. Real-Time Intelligence venter til afvisningsfasen med 60 minutters fremtidig kapacitet for at begynde begrænsningen. Denne funktionsmåde sikrer, at brugerne fortsat kan nyde godt af ydeevnen i realtid, selv i perioder med høj efterspørgsel.

På samme måde rapporteres næsten alle handlinger i kategorien Warehouse som baggrund for at drage fordel af 24-timers udjævning af aktiviteter for at give mulighed for de mest fleksible forbrugsmønstre. Hvis du klassificerer alle datawarehousing som baggrund , forhindres spidsbelastninger af CU-udnyttelsen i at udløse begrænsning for hurtigt. Nogle anmodninger kan udløse en kæde af handlinger, der er begrænset forskelligt. Når en interaktiv handling starter en kæde, der indeholder en baggrundshandling, kan baggrundshandlingen blive underlagt begrænsning som en interaktiv handling.

Interaktive klassificeringer og baggrundsklassifikationer til begrænsning og udjævning

Nogle administratorer vil måske bemærke, at handlinger nogle gange er klassificeret som interaktive og udjævnede som baggrund eller omvendt. Denne skelnen sker, fordi Fabrics begrænsningssystemer skal anvende begrænsningsregler, før en anmodning begynder at køre.

Begrænsningssystemet forsøger at kategorisere handlinger præcist ved indsendelse. Når en handling begynder at køre, bliver der nogle gange mere detaljerede oplysninger tilgængelige, som ændrer kategoriseringen. I tvetydige scenarier går begrænsningssystemet tilbage til at klassificere handlinger som baggrund, hvilket er i brugerens bedste interesse.

Spor overages og afviste handlinger

Du kan se, om din kapacitet er overbelastet, ved at gennemse diagrammet Udnyttelse i appen Microsoft Fabric Capacity Metrics. En spidsbelastning, der går over linjen, angiver en overbelastning. Hvis du vil undersøge overtiden yderligere, skal du gå videre til tidspunktets side. Du kan derefter gennemse både dine interaktive handlinger og baggrundshandlinger og se, hvilke der var ansvarlige for overgangene.

Da udnyttelse på mere end 100% ikke automatisk betyder begrænsning, skal du bruge begrænsningsdiagrammet , når du evaluerer overforbrug. Herfra kan du åbne en tabel, der viser minutter til nedbrænding, et diagram med tilføjelse, nedbrænding og akkumuleret procent m.m. Minutter til nedbrænding estimerer, hvor lang tid det tager at brænde ned, hvis der ikke forekommer flere handlinger i kapaciteten.

Hvis du vil have vist en visuel oversigt over overudnyttelse af kapacitet, herunder overførsel, kumulativ og nedbrænding af udnyttelsesdata, skal du gå til fanen Overforbrug. Du kan ændre overbelastningsvisualiseringen til at vise 10 minutter, 60 minutter og 24 timer.

Detailudledning i appen Microsoft Fabric Capacity Metrics giver administratorer mulighed for at se handlinger, der blev afvist under en begrænsningshændelse. Der er begrænsede oplysninger om disse handlinger, da de aldrig fik lov til at starte. Administratoren kan se produktet, brugeren, handlings-id'et og tidspunktet, hvor anmodningen blev sendt. Når en anmodning afvises, modtager slutbrugerne en fejlmeddelelse, der beder dem om at prøve igen senere.

Fakturerbar og ikke-fakturerbar beregning

Når du gennemser kapacitetsforbrug i appen med kapacitetsmålepunkter, faktureres nogle handlinger, og andre faktureres ikke. Det er kun fakturerbare handlinger, der er inkluderet i begrænsningsberegninger. Prøveversionsfunktioner kan generere handlinger, der ikke kan faktureres. Brug handlinger, der ikke kan faktureres, til at planlægge, så kapaciteten tilpasses korrekt, når disse prøveversionsfunktioner faktureres.

Relateret indhold

• Installér appen Microsoft Fabric Capacity Metrics for at overvåge Fabric-kapaciteter.
• Sådan tilpasser du størrelsen på din kapacitet.