Forstå Fabric-kapasitetsbegrensningspolitikken

Throttling skjer når operasjoner bruker flere kapasitetsenheter (CU) sekunder enn kapasitets-SKU-en tillater. Kapasitetsenheter måler den tilgjengelige datakraften for hver SKU. For mye begrensning kan resultere i en redusert sluttbrukeropplevelse. En Microsoft Fabric-leier kan opprette flere kapasiteter og tilordne arbeidsområder til en bestemt kapasitet for fakturering og skalering.

Fabric påfører throttling på kapasitetsnivå. Mens én kapasitet, eller sett med arbeidsområder, kan oppleve redusert ytelse på grunn av overbelastning, kan andre kapasiteter fortsette å fungere normalt. Når én kapasitet produserer funksjoner som OneLake-elementer og en annen kapasitet bruker dem, avgjør throttling-tilstanden til den forbrukende kapasiteten om den struper kall til varen.

Hvordan Fabric balanserer ytelse og pålitelighet

Fabric leverer rask ytelse til sine kunder. Oppgaver som kan ta flere minutter å fullføre på andre plattformer, kan fullføres på bare sekunder på Fabric. Store operasjoner kan kjøres når som helst på døgnet uten behov for nøye planlegging, fordi Fabric sprer beregningen for disse operasjonene over en lengre tidsperiode, uten å bremse operasjonen. Fabric muliggjør denne oppførselen ved å bruke innebygd bursting og smoothing. Disse funksjonene lar kapasiteter selvstyre og helbrede seg selv når midlertidige økninger i bruken ellers ville ført til at andre systemer svikter eller blir tregere.

Bursting: Bruk mer datakraft enn kapasiteten SKU gir

For å sikre rask ytelse bruker Fabric bursting for å kjøre operasjonene så raskt som mulig. Med bursting kan operasjoner midlertidig bruke mer beregning enn den provisjonerte beregningen for kapasitets-SKU. På grunn av sprekk får du resultater uten å vente. En mindre kapasitet kan også bruke bursting for å drive større operasjoner som normalt ville kreve en dyrere kapasitet.

Utjevning: Spre CU-bruken over fremtidige tidspunkter

For å unngå å straffe deg når operasjoner drar nytte av bursting, jevner Fabric ut, eller gjennomsnitter, CU-bruken av en operasjon over lengre tidsrammer. Denne oppførselen sikrer at du kan nyte jevn rask ytelse uten throttling.

Utjevning distribuerer forbruk av CU over fremtidige tidspunkter. Timepoints i Fabric er 30 sekunder lange. De neste 24 timene inneholder 2 880 tidspunkter. Fabric håndterer automatisk mengden forbrukte CU-er i hvert tidspunkt.

En operasjons utnyttelsestype bestemmer antall tidspunkter Fabric bruker for utjevning. Lær om stoffoperasjoner.

• Fabric jevner interaktive operasjoner over minst fem minutter, og opptil 64 minutter avhengig av hvor mye CU-bruk de bruker.
• Fabric jevner ut bakgrunnsoperasjoner over 24 timer fordi de vanligvis har lange kjøretider og stort forbruk av CU.

På grunn av utjevning gjelder bare en del av CU-bruken for en operasjon for hvert enkelt tidspunkt, noe som reduserer begrensningen totalt sett. Jevnet CU-bruk akkumuleres etter hvert som operasjoner kjøres. Fremtidig kapasitet, som er CU-ene tilgjengelig på fremtidige tidspunkter, betaler for jevn bruk fordi kapasiteten kjører kontinuerlig.

Bursting og smoothing jobber sammen for å gjøre det lettere for deg å gjøre jobben din. For eksempel bruker du vanligvis tid på å planlegge jobber og spre dem utover dagen. Med utjevning fordeler Fabric beregningskostnaden for bakgrunnsjobber over 24 timer. Som et resultat kan planlagte jobber kjøre samtidig uten å forårsake noen topper som ellers ville blokkert jobbene fra å starte. Samtidig kan du nyte jevnt rask ytelse uten å vente på at trege oppdrag skal bli ferdige eller kaste bort tid på å administrere timeplaner.

Begrensningsutløsere og begrensningsfaser

Selv om kapasiteter har innebygd utjevning som reduserer virkningen av pigger i bruken, er det fortsatt mulig å overbelaste en kapasitet ved å kjøre for mange operasjoner.

Kapasiteten struper automatisk nye operasjoner når den er overbelastet. Begrensning skjer i progressive trinn for å minimere innvirkningen på viktige oppgaver som dataoppdateringer.

Selv når en kapasitet opererer over 100% utnyttelse, bruker ikke Fabric umiddelbart begrensning. I stedet gir kapasiteten overtidsbeskyttelse som lar deg bruke 10 minutter av fremtidig kapasitet uten å begrense kapasiteten. Denne oppførselen gir begrenset innebygd beskyttelse mot overspenninger, samtidig som brukerne får jevnt høy ytelse uten forstyrrelser.

Begrensningen starter når en kapasitet bruker opp alle cu-ressursene de neste 10 minuttene. Den første fasen av throttling gir 20 sekunders forsinkelser til nye interaktive operasjoner. Den andre fasen av throttling avviser nye interaktive operasjoner når en kapasitet bruker opp alle sine CU-ressurser i løpet av den neste timen. I denne fasen kan bakgrunnsoperasjoner starte og kjøre. Den tredje fasen av struping avviser alle nye forespørsler, både interaktive og bakgrunnsforespørsler, når kapasiteten bruker opp alle tilgjengelige CU-ressurser de neste 24 timene. Kapasiteten fortsetter å strupe forespørsler til du betaler ned de forbrukte CU-ene.

Tabellen nedenfor oppsummerer throttling-triggerne og stadiene.

Eksempel: Hvordan glatting reduserer throttling for en bakgrunnsoperasjon

Her er et illustrerende eksempel på hvordan utjevning fungerer for én bakgrunnsoperasjon som brukte 1 CU-time (bruken tilsvarte 1 CU i 1 time). Fabric gjør bakgrunnsoperasjonene jevnere over 24 timer. En bakgrunnsoperasjons bidrag til et hvilket som helst tidspunkt er operasjonens CU-timer delt på SKU-ens CU-timer over glattingsperioden. En F2 gir 2 CU-er, eller 48 CU-timer per dag (2 CU-er multiplisert med 24 timer). Denne jobben bidrar med 1 CU-time / 48 CU-timer = ~2,1% til hvert tidspunkt. Effekten på 10- og 60-minutters throttlingsgrensene er også ~2,1%.

Her er detaljene som støtter eksemplet:

1 CU-time = 3 600 CU-sekunder (1 CU multiplisert med 60 minutter per time og 60 sekunder per minutt).

Hvert tidspunkt varer i 30 sekunder. På 24 timer er det 2880 tidspunkter (24 timer * 60 minutter * 2 tidspunkter per minutt).

Fordi utjevning sprer de 3 600 CU-sekundene over 24 timer, bidrar jobben med 3 600 CU-sekunder / 2 880 tidspunkter til hvert 30-sekunders tidspunkt. Så det bidrar med 1,25 CU-sekunder per tidspunkt.

10-minutters throttling-prosenten baseres på totale tilgjengelige kreditter i løpet av de neste 10 minuttene med kapasitetsoppetid.

En F2-kapasitet gir 2 CU-er. I hvert tidspunkt har en F2 2 CU-er multiplisert med 30 sekunder = 60 CU-sekunder med beregning.

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

På 10 minutter har F2 2 CU-er multiplisert med 600 sekunder = 1 200 CU-sekunder med beregning.

Den delen av bakgrunnsjobben som utjevning sprer seg til de neste 10 minuttene av kapasitet, er 1,25 CU-sekunder multiplisert med 20 tidspunkter = 25 CU-sekunder.

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

Tilsvarende er den 60-minutters begrensningsprosenten for bakgrunnsjobben også ~2,1%.

Selv om bakgrunnsoperasjonen brukte flere CU-er enn tilgjengelig i løpet av de neste 10 minuttene (den brukte seks ganger så mye), er ikke F2-kapasiteten begrenset fordi utjevning sprer de totale CU-ene over 24 timer. På grunn av utjevning gjelder bare en liten del av de brukte CU-ene for hvert enkelt tidspunkt.

Overages, carryforward og burndown

Når operasjoner bruker mer kapasitet enn det SKU-en støtter på et enkelt tidspunkt, beregner systemet en overforbruk. Systemet beregner overtidsperioder etter utjevning. Hvis overskridelser overstiger det tillatte 10-minutters throttlingsvinduet, blir de carryforward-kreditter .

Beskyttelse mot overforbruk sikrer at kapasiteten ikke begrenses før det 10 minutter lange begrensningsvinduet er fullt. Det reduserer hyppigheten av interaktive forsinkelser som midlertidige økninger i bruken medfører.

Fabric anvender overførings-CU-ene på hvert påfølgende tidspunkt. Hvis et tidspunkt ikke er fullt, reduserer de ubrukte kredittene antall overføringskreditter . Denne reduksjonen er burndown.

Begrensningshåndhevelse fortsetter til ubrukt kapasitet betaler alle overførings-CUer.

Overvåkingskapasitet for begrensning

Kapasitetsadministratorer kan sette opp e-postvarsler for kapasitetsterskler ved å bruke Capacity Overview Events. Administratorer kan også bruke måledataappen for kapasitet til å se gjennom begrensningsnivåene for kapasiteten.

Høyrestørrelse og optimalisering av en kapasitet

Konsekvent høye begrensningsnivåer indikerer behovet for å laste inn saldo på tvers av flere kapasiteter eller øke kapasitetens SKU-størrelse. For F-SKU-er kan du skalere kapasiteten. Å skalere mellom SKU-er på motsatte sider av grensen mellom F256 og F512 kan gi en tregere opplevelse.

Slik finner du ut at kapasitetsbegrensning forekommer

Når en kapasitet avviser forespørsler, ser du spesifikke feilkoder og feiltekst:

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

Når en kapasitet er overbelastet, kan en kapasitetsadministrator bruke måledataappen for stoffkapasitet til å bekrefte begrensningen.

• Systemhendelser-tabellen på Databehandling-siden viser loggen over begrensningshendelser.
• Begrensningsdiagrammene på Databehandling-siden vises når jevnt bruk overskrider én av begrensningsgrensene.

Slik stopper du begrensningen når det oppstår

Kapasiteter er selvhelbredende, så du kan alltid vente til overbelastningstilstanden er over før du sender inn nye forespørsler.

Men for å stoppe raskere throttling kan du bruke følgende strategier.

Når du bruker F SKU-kapasiteter, stopper du begrensningen:

• Øk SKU-en midlertidig. Ved å øke SKU-en, brenner du ned bæring raskere fordi hvert tidspunkt har mer inaktiv kapasitet.
• Ta en pause og fortsett så kapasiteten din. Stansing av en kapasitet resulterer i en faktureringshendelse for akkumulert fremtidig kapasitetsbruk. Når en kapasitet starter eller gjenopptas, har den null fremtidig kapasitetsbruk, slik at den kan godta nye operasjoner umiddelbart. Å pause kan gjøre innhold tildelt kapasiteten utilgjengelig, så sørg først for at kapasiteten ikke er i bruk.
• Fakturering for kapasitetsoverskridelse kan også forhindre at throttling skjer; den koster imidlertid tre ganger den normale kapasitetssatsen. For mer informasjon, se Aktiver kapasitetsoverskridelse.

Når du bruker P SKU-kapasiteter, stopper du begrensningen:

• Aktiver Autoskala for P-kapasiteten.

Operasjoner om bord begrenses ikke

Begrensning påvirker bare operasjoner som er forespurt etter at kapasiteten starter begrensningen. Alle operasjoner, inkludert langvarige som du sendte inn før strupingen startet, kan kjøres til fullføring. Denne oppførselen sikrer at operasjonene fullføres, selv under økninger i CU-bruk.

Sammensatt begrensningsbeskyttelse

I Fabric utløser én operasjon ofte andre elementer eller arbeidsbelastninger å fullføre. Det finnes mange eksempler, men en vanlig en viser en rapport. Hvert visualobjekt i rapporten kjører en spørring mot en underliggende semantisk modell. Den semantiske modellen kan også lese data fra OneLake for å gi spørringsresultatet. Hver av disse forespørslene danner en kjede.

Når det er en kjede av samtaler, er det risiko for sammensatt throttling, som oppstår når Fabric bruker throttling mer enn én gang på samme forespørsel. Fabric har innebygd compound-throttling-beskyttelse som reduserer sannsynligheten for compound-throttling. Arbeidsbelastninger kan velge denne beskyttelsen.

Når arbeidsbelastninger støtter beskyttelse mot sammensatt throttling, struper Fabric en forespørsel kun én gang for hver kapasitet som deltar i kjeden. Begrensningsbeslutningen oppstår når forespørselen starter og gjelder for alle operasjoner i kjeden.

Hvis en kjede er avhengig av mer enn én kapasitet, håndhever hver kapasitet sin throttling én gang for den første forespørselen den mottar i kjeden.

Følgende arbeidsbelastningsopplevelser støtter sammensatt begrensning:

• Semantiske modeller som kobler seg til andre semantiske modeller ved å bruke DirectQuery.
• DAX-spørringer fra paginerte rapporter til semantiske modeller.

Begrensningsvirkemåte er spesifikk for fabric-arbeidsbelastninger

Selv om de fleste Fabric-produkter følger de tidligere nevnte reglene for stryping, finnes det noen unntak.

For eksempel har Fabric eventstreams mange operasjoner som kan pågå i flere år etter at de har startet. Å begrense nye hendelsesstrømsoperasjoner ville ikke gi mening, så i stedet reduserer Fabric mengden CU-ressurser som brukes til å holde strømmen åpen til kapasiteten er i god stand igjen.

Et annet unntak er Real-Time Intelligence, som ikke ville vært sanntids hvis den forsinket operasjonene med 20 sekunder. Som et resultat bruker Real-Time Intelligence ikke den første fasen av begrensning med 20-sekunders forsinkelser på 10 minutter med fremtidig kapasitet. Real-Time Intelligence venter til avvisningsfasen på 60 minutter med fremtidig kapasitet til å begynne å begrense. Denne oppførselen sikrer at du kan fortsette å nyte sanntidsytelse selv i perioder med høy etterspørsel.

På samme måte rapporterer Fabric nesten alle operasjoner i lagerkategorien som bakgrunn for å dra nytte av 24-timers utjevning av aktivitet og muliggjøre de mest fleksible bruksmønstrene. Klassifisering av alle datalagre som bakgrunn hindrer topper av CU-utnyttelse fra å utløse begrensning for raskt. Noen forespørsler kan utløse en kjede av operasjoner som Fabric begrenser annerledes. Når en interaktiv operasjon starter en kjede som inkluderer en bakgrunnsoperasjon, kan Fabric begrense bakgrunnsoperasjonen som en interaktiv operasjon.

Interaktive klassifiseringer og bakgrunnsklassifiseringer for begrensning og utjevning

Du vil kanskje legge merke til at Fabric noen ganger klassifiserer operasjoner som interaktive og glatter dem ut som bakgrunn, eller omvendt. Dette skillet skjer fordi Fabric's throttling-systemer må anvende throttling-regler før en forespørsel begynner å kjøre.

Begrensningssystemet forsøker å kategorisere operasjoner nøyaktig ved innsending. Noen ganger når en operasjon begynner å kjøre, blir mer detaljert informasjon tilgjengelig som endrer kategoriseringen. I tvetydige situasjoner faller throttling-systemet tilbake til å klassifisere operasjoner som bakgrunn, noe som er i din beste interesse.

Spore overforbruk og avviste operasjoner

For å se om kapasiteten din er overbelastet, se på utnyttelsesdiagrammet i Microsoft Fabric Capacity Metrics-appen. En pigg som går over linjen indikerer en overforbruk. Hvis du vil undersøke overforbruket ytterligere, driller du gjennom til tidspunktsiden. Gå deretter gjennom både dine interaktive og bakgrunnsoperasjoner for å se hvilke som forårsaket overskridelsene.

Fordi utnyttelse over 100% ikke automatisk betyr throttling, bruk Throttling-diagrammet når du vurderer overforbruk. Derfra åpner du en tabell som viser minutter til burndown, et diagram med add, burndown og kumulativ prosent, og mer. Minutter å brenne ned estimerer hvor lang tid gjenstående ville ta hvis det ikke oppstår flere operasjoner i kapasiteten.

For å se en visuell historikk over eventuell overforbruk av kapasitet, inkludert overføring, kumulativ og nedtrapping av utnyttelsesdata, gå til fanen Overforbruk. Endre overtidsskalaen slik at den viser 10 minutter, 60 minutter og 24 timer.

Microsoft Fabric Capacity Metrics-appens drilldown viser operasjoner som Fabric avviste under en throttling-hendelse. Det finnes begrenset informasjon om disse operasjonene fordi de aldri startet. Du kan se produktet, brukeren, operasjons-ID og tidspunktet for forespørselen. Når Fabric avviser en forespørsel, mottar sluttbrukerne en feilmelding som ber dem prøve igjen senere.

Fakturerbar og ikke-fakturerbar beregning i throttling-beregninger

Når du ser gjennom kapasitetsbruken i måledataappen for kapasitet, kan noen operasjoner faktureres, og andre kan ikke faktureres. Throttling-beregninger inkluderer kun fakturerbare operasjoner. Noen forhåndsvisningsfunksjoner kan generere ikke-fakturerbare operasjoner. Bruk ikke-fakturerbare operasjoner for å planlegge på forhånd, slik at du dimensjonerer kapasiteten riktig for når disse forhåndsvisningsfunksjonene blir fakturerbare.

Relatert innhold

• Installer Microsoft Fabric Capacity Metrics-appen for å overvåke stoffkapasiteter.
• Slik endrer du størrelsen på kapasiteten.
• Utforsk Fabric kapasitetsoversiktsarrangementer i Fabric Real-Time hub