Forstå Fabric-kapacitetsbegrænsningspolitikken

Throttling opstår, når operationer bruger flere kapacitetsenheder (CU) sekunder, end kapacitets-SKU'en tillader. Kapacitetsenheder måler den tilgængelige beregningskraft for hver SKU. 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.

Fabric påfører throttling på kapacitetsniveauet. Mens én kapacitet eller et sæt arbejdsområder kan opleve nedsat ydeevne på grund af overbelastning, kan andre kapaciteter fortsætte med at køre normalt. Når én kapacitet producerer funktioner som OneLake-elementer, og en anden kapacitet forbruger dem, bestemmer forbrugskapacitetens throttling-tilstand, om den begrænser kald til varen.

Hvordan Fabric balancerer ydeevne og pålidelighed

Fabric leverer hurtig ydeevne til sine kunder. Opgaver, der kan tage flere minutter at udføre på andre platforme, kan afsluttes på få sekunder på Fabric. Store operationer kan køre når som helst på dagen uden behov for omhyggelig planlægning, fordi Fabric fordeler beregningen for disse operationer over en længere periode uden at sænke hastigheden. Fabric muliggør denne adfærd ved hjælp af indbygget bursting og smoothing. Disse funktioner gør det muligt for kapaciteter at selvstyre og hele, når midlertidige spidser i forbruget ellers ville få andre systemer til at fejle eller gå langsommere.

Bursting: Brug mere compute end kapaciteten, SKU'en leverer

For at sikre hurtig ydeevne bruger Fabric bursting til at køre operationer så hurtigt som muligt. Med bursting kan operationer midlertidigt bruge mere compute end den provisionerede compute for kapacitets-SKU'en. På grund af at springe får du resultater uden at vente. En mindre kapacitet kan også bruge bursting til at drive større operationer, som normalt ville kræve en dyrere kapacitet.

Udjævning: Spred CU-forbruget over fremtidige tidspunkter

For at undgå at straffe dig, når operationer drager fordel af bursting, udjævner eller gennemsnitter Fabric CU-forbruget af en operation over en længere tidsramme. Denne adfærd sikrer, at du kan nyde konsekvent hurtig ydeevne uden throttling.

Udjævning distribuerer forbrugt CU-forbrug i forhold til fremtidige tidspunkter. Tidspunkter i Fabric er 30 sekunder lange. De næste 24 timer indeholder 2.880 tidspunkter. Fabric håndterer automatisk mængden af forbrugte CU'er i hvert tidspunkt.

En operations udnyttelsestype bestemmer antallet af tidspunkter, som Fabric bruger til udjævning. Få mere at vide om Fabric-handlinger.

• Fabric gør interaktive operationer smidige over mindst fem minutter og op til 64 minutter afhængigt af, hvor meget CU-forbrug de bruger.
• Fabric gør baggrundsoperationerne lettere over en 24-timers periode, fordi de typisk har lange driftstider 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. Fremtidig kapacitet, som er de CU'er, der er tilgængelige på fremtidige tidspunkter, betaler for en jævn udnyttelse, fordi kapaciteten kører kontinuerligt.

At sprænge og udjævne arbejder sammen for at gøre det lettere for dig at udføre dit arbejde. For eksempel bruger du typisk tid på at planlægge opgaver og sprede dem ud over dagen. Med smoothing fordeler Fabric compute-omkostningerne for baggrundsopgaver over 24 timer. Som følge heraf kan planlagte jobs køre samtidig uden at forårsage nogen spikes, der ellers ville blokere jobs fra at starte. Samtidig kan du nyde konsekvent hurtig præstation uden at vente på, at langsomme opgaver bliver færdige eller spilde tid på at styre arbejdsplaner.

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 operationer, når den er overbelastet. 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. I stedet giver kapaciteten overforbrugsbeskyttelse , der lader dig bruge 10 minutters fremtidig kapacitet uden throttling. Denne adfærd giver begrænset indbygget beskyttelse mod overspændinger, samtidig med at brugerne får konsekvent hurtig ydeevne uden forstyrrelser.

Begrænsningen starter, når en kapacitet bruger alle sine CU-ressourcer i de næste 10 minutter. Den første fase af throttling giver 20 sekunders forsinkelser til nye interaktive operationer. Den anden fase af throttling afviser nye interaktive operationer, når en kapacitet bruger alle sine CU-ressourcer i den næste time. I denne fase kan baggrundsoperationer starte og køre. Den tredje fase af throttling afviser alle nye anmodninger, både interaktive og baggrundsforespørgsler, 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 du har betalt de forbrugte CU'er af.

Følgende tabel opsummerer throttling-triggerne og stadierne.

Eksempel: Hvordan udglatning reducerer throttling for en baggrundsoperation

Her er et illustrativt eksempel på, hvordan udjævning fungerer for en baggrundsoperation, der brugte 1 CU-time (dens brug svarede til 1 CU for 1 time). Fabric gør baggrundsoperationerne lettere over 24 timer. En baggrundsoperations bidrag til et hvilket som helst tidspunkt er operationens CU-timer divideret med SKU'ens CU-timer over udjævningsperioden. En F2 giver 2 CU'er, eller 48 CU-timer om dagen (2 CU'er ganget med 24 timer). Dette job bidrager med 1 CU-time / 48 CU-timer = ~2,1% til hvert tidspunkt. Effekten på 10-minutters og 60-minutters gasbegrænsningerne er også ~2,1%.

Her er de detaljer, der understøtter eksemplet:

1 CU-time = 3.600 CU-sekunder (1 CU ganget med 60 minutter i timen og 60 sekunder i minuttet).

Hvert tidspunkt varer 30 sekunder. På 24 timer er der 2.880 tidspunkter (24 timer * 60 minutter * 2 timepunkter pr. minut).

Fordi udglatning fordeler de 3.600 CU-sekunder over 24 timer, bidrager jobbet med 3.600 CU-sekunder / 2.880 tidspunkter til hvert 30-sekunders tidspunkt. Så det bidrager med 1,25 CU-sekunder pr. tidspunkt.

10-minutters throttling-procenten er baseret på de samlede tilgængelige CU'er i de næste 10 minutters kapacitetsoppetid.

En F2-kapacitet giver 2 CU'er. I hvert tidspunkt har en F2 2 CU'er ganget med 30 sekunder = 60 CU-sekunders beregning.

Bidraget fra baggrundsjobbet til et individuelt tidspunkt er 1,25 CU-sekunder / 60 CU-sekunder = ~2,1% af et individuelt tidspunkt.

På 10 minutter har F2 2 CU'er ganget med 600 sekunder = 1.200 CU-sekunders beregning.

Den del af baggrundsjobbet, hvor udjævningen spreder sig til de næste 10 minutters kapacitet, er 1,25 CU-sekunder ganget med 20 tidspunkter = 25 CU-sekunder.

Så 10-minutters throttling-procenten er 25 CU-sekunder / 1.200 CU-sekunder = ~2,1%.

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

Selvom baggrundsdriften forbrugte flere CU'er end tilgængeligt i den næste 10-minutters periode (den brugte seks gange så meget), er F2-kapaciteten ikke begrænset, fordi udjævning spreder det samlede CU'er 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 operationer bruger mere kapacitet, end SKU'en understøtter på et enkelt tidspunkt, beregner systemet en overforbrug. Systemet beregner overforbrug efter udjævning. Hvis overforbruget overstiger det tilladte 10-minutters throttling-vindue, bliver de til carryforward-CU'er .

Beskyttelse mod overbesættelse sikrer, at kapaciteten ikke begrænses, før 10-minutters begrænsningsvinduet er fuldt. Det reducerer hyppigheden af interaktive forsinkelser, som midlertidige spidser i udnyttelsen medfører.

Fabric anvender de videreførte CU'er på hvert efterfølgende tidspunkt. Hvis et tidspunkt ikke er fuldt, reducerer de ubrugte CU'er antallet af carryforward-CU'er . Denne reduktion er 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 opsætte e-mailadvarsler for kapacitetstærskler ved at bruge Capacity Overview Events. 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. For F-SKU'er kan du skalere kapaciteten. Skalering mellem SKU'er på hver sin side af F256- og F512-grænsen kan resultere i en langsommere oplevelse.

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

Når en kapacitet afviser anmodninger, ser du specifikke fejlkoder og fejltekst:

• Statuskode CapacityLimitExceeded
• Fejlmeddelelse Your organization's Fabric compute capacity has exceeded its limits. Try again later.
• Fejlmeddelelse Cannot load model due to reaching capacity limits

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

• Tabellen Systemhændelser på siden Compute viser historikken for begrænsningshændelser.
• 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.

Men for at stoppe hurtigere throttling kan du bruge følgende strategier.

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.
• Pause og genoptag så 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. At sætte på pause kan gøre indhold, der er tildelt kapaciteten, utilgængeligt, så sørg først for, at kapaciteten ikke er i brug.
• Fakturering for kapacitetsoverforbrug kan også forhindre, at throttling forekommer; dog koster det tre gange den normale kapacitet. For mere information, se Aktiver kapacitetsoverskridelse.

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 operationer, inklusive de langvarige som du indsendte før throttling begyndte, kan køre til afslutning. Denne adfærd sikrer, at operationerne fuldføres, selv under stigninger i CU-forbruget.

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 data fra 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 throttling, som opstår, når Fabric anvender throttling mere end én gang på den samme anmodning. Fabric har indbygget compound-throttling-beskyttelse, der mindsker risikoen for compound-throttling. Arbejdsbelastninger kan vælge denne beskyttelse.

Når arbejdsbelastninger understøtter beskyttelse mod sammensat throttling, throttler Fabric kun en anmodning é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, håndhæver hver kapacitet sin throttling én gang for den første anmodning, den modtager i kæden.

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

• Semantiske modeller, der forbinder til andre semantiske modeller ved hjælp af DirectQuery.
• 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 førnævnte regler for throttling, findes der nogle undtagelser.

For eksempel har Fabric eventstreams mange operationer, der kan køre i årevis efter, de er startet. At begrænse nye eventstream-operationer ville ikke give mening, så i stedet reducerer Fabric mængden af CU-ressourcer, der afsættes til at holde streamen åben, indtil kapaciteten igen er i god stand.

En anden undtagelse er Real-Time Intelligence, som ikke ville være realtids, hvis den forsinkede operationerne 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 adfærd sikrer, at du fortsat kan nyde realtidspræstationer, selv i perioder med høj belastning.

Tilsvarende rapporterer Fabric næsten alle operationer i lagerkategorien som baggrund for at udnytte 24-timers udjævning af aktiviteten og muliggøre de mest fleksible brugsmø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 operationer, som Fabric regulerer forskelligt. Når en interaktiv operation starter en kæde, der inkluderer en baggrundsoperation, kan Fabric begrænse baggrundsoperationen som en interaktiv operation.

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

Du vil måske bemærke, at Fabric nogle gange klassificerer operationer som interaktive og udglatter dem som baggrund, eller omvendt. Denne sondring sker, fordi Fabric's throttling-systemer skal anvende throttling-regler, 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 falder throttling-systemet tilbage på at klassificere operationer som baggrund, hvilket er i din bedste interesse.

Spor overages og afviste handlinger

For at se, om din kapacitet er overbelastet, kan du gennemgå udnyttelsesdiagrammet i Microsoft Fabric Capacity Metrics-appen. En spidsbelastning, der går over linjen, angiver en overbelastning. Hvis du vil undersøge overtiden yderligere, skal du gå videre til tidspunktets side. Gennemgå derefter både dine interaktive og baggrundsoperationer for at se, hvilke der forårsagede overskridelserne.

Fordi udnyttelse over 100% ikke automatisk betyder throttling, så brug Throttling-diagrammet , når du vurderer overforbrug. Derfra åbner du en tabel, der viser minutter til burndown, et diagram med add, burndown og kumulativ procentdel og mere. Minutter til nedbrænding estimerer, hvor lang tid det tager at brænde ned, hvis der ikke forekommer flere handlinger i kapaciteten.

For at se en visuel historik over eventuel overudnyttelse af kapacitet, herunder carryforward, kumulativ og nedbrænding af udnyttelsesdata, gå til fanen Overages. Skift overtidsskalaen til at vise 10 minutter, 60 minutter og 24 timer.

Microsoft Fabric Capacity Metrics-appens drilldown viser operationer, som Fabric afviste under en throttling-hændelse. Der er begrænset information om disse operationer, fordi de aldrig blev startet. Du kan se produktet, brugeren, operations-ID'et og tidspunktet for anmodningen. Når Fabric afviser en anmodning, modtager slutbrugerne en fejlmeddelelse, der beder dem prøve igen senere.

Fakturerbar og ikke-fakturerbar beregning i throttling-beregninger

Når du gennemser kapacitetsforbrug i appen med kapacitetsmålepunkter, faktureres nogle handlinger, og andre faktureres ikke. Throttling-beregninger inkluderer kun fakturerbare operationer. Nogle preview-funktioner kan generere ikke-fakturerbare operationer. Brug ikke-fakturerbare operationer til at planlægge fremad, så du dimensionerer din kapacitet korrekt, når disse forhåndsvisningsfunktioner bliver fakturerbare.

Relateret indhold

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