Stoffbegrensningspolicyen

Begrensning oppstår når operasjoner bruker flere databehandlingsenheter sekunder (CUer) enn kapasitets-SKU-en tillater. 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.

Begrensning brukes på kapasitetsnivå, noe som betyr at mens én kapasitet, eller et sett med arbeidsområder, opplever redusert ytelse på grunn av overbelastning, kan andre kapasiteter fortsette å kjøre normalt. I tilfeller der funksjoner som OneLake-artefakter produseres i én kapasitet og forbrukes av en annen, bestemmer begrensningstilstanden for den forbrukskapasiteten om kall til artefakten begrenses.

Balanse mellom ytelse og pålitelighet

Fabric er designet for å levere 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øre når som helst på dagen uten behov for nøye planlegging fordi beregningen for disse operasjonene er spredt over en lengre tidsperiode, uten å redusere hastigheten på operasjonen. Stoff muliggjør dette ved hjelp av innebygd sprengning og glatting. De gjør det mulig for kapasiteter å være selvadministrerende og selvhelbredende når midlertidige pigger i bruken ellers ville føre til at andre systemer mislykkes eller bremser ned.

Sprengning

For å sikre rask ytelse bruker Fabric sprengning for å la operasjoner kjøre så fort de kan. Bursting gjør det mulig for operasjoner å bruke mer databehandling midlertidig enn den klargjorte databehandlingen for SKU-en for kapasiteten. På grunn av oppsprengning får brukerne resultater raskt uten å vente. Bursting gjør det også mulig for en mindre kapasitet å kjøre større operasjoner som normalt ville kreve en dyrere kapasitet.

Utjevning

For å unngå å straffe brukere når operasjonene drar nytte av sprengning, stoffutjevninger eller gjennomsnitt, bruker CU-operasjonen over en lengre tidsramme. Denne virkemåten sikrer at brukerne kan nyte konsekvent rask ytelse uten å oppleve begrensning.

Utjevning distribuerer forbruk av CU over fremtidige tidspunkter. Timepoints i Fabric er 30 sekunder lange. Det er 2880 tidspunkter i løpet av de neste 24 timene. Fabric administrerer automatisk mengden forbruker-CUer i hvert tidspunkt.

Utnyttelsestypen for en operasjon bestemmer antallet tidspunkter som brukes til utjevning. Lær om stoffoperasjoner.

• Interaktive operasjoner blir jevnet ut over minst fem minutter, og opptil 64 minutter, avhengig av hvor mye CU-bruk de bruker.
• Bakgrunnsoperasjoner blir jevnet ut over en 24-timers periode fordi de vanligvis har lange kjøretider og stort CU-forbruk.

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. Jevn bruk betales av fremtidig kapasitet, som er CUs tilgjengelig i fremtidige tidspunkter, fordi kapasiteten kjører kontinuerlig.

Sprengning og utjevning fungerer sammen for å gjøre det enklere for kapasitetsbrukere å gjøre arbeidet sitt. Brukere bruker for eksempel vanligvis tid på å planlegge jobber og spre dem ut i løpet av dagen. Med utjevning blir beregningskostnaden for bakgrunnsjobber jevnet ut over 24 timer. Dette betyr at planlagte jobber kan kjøre samtidig uten å forårsake noen pigger som ellers ville blokkere jobber fra å starte. Samtidig kan brukere nyte konsekvent rask ytelse uten å vente på trege jobber for å fullføre eller kaste ut tid på å administrere jobbtidsplaner.

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 begrenser 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 overforbruksbeskyttelse som gjør det mulig å bruke 10 minutter fremtidig kapasitet uten begrensning. Denne virkemåten gir en begrenset innebygd beskyttelse mot overspenninger, samtidig som brukerne konsekvent får rask ytelse uten forstyrrelser.

Begrensningen starter når en kapasitet bruker opp alle cu-ressursene de neste 10 minuttene. Den første fasen av begrensningen bruker 20 sekunders forsinkelser på nye interaktive operasjoner. Den andre fasen av begrensningen avviser nye interaktive operasjoner når en kapasitet bruker opp alle sine CU-ressurser for neste time. I denne fasen har bakgrunnsoperasjoner tillatelse til å starte og kjøre. Den tredje fasen av begrensning av avvisning av alle nye forespørsler, interaktive og bakgrunner, når kapasiteten bruker opp alle tilgjengelige CU-ressurser for de neste 24 timene. Kapasiteten fortsetter å begrense forespørsler til den forbrukte CU er betalt.

Merk

Microsoft prøver å forbedre kundefleksibilitet ved bruk av tjenesten, samtidig som de balanserer behovet for å administrere kundekapasitetsbruk. Av denne grunn kan Microsoft endre eller oppdatere stoffbegrensningspolicyen.

Tabellen oppsummerer begrensningsutløsere og faser.

Bruk	Policygrenser	Innvirkning på plattformpolicyopplevelse
Bruk <= 10 minutter	Beskyttelse mot overforbruk	Jobber kan bruke 10 minutter av fremtidig kapasitetsbruk uten begrensning.
Bruk 10 minutter <<= 60 minutter	Interaktiv forsinkelse	Brukerspørrte interaktive jobber forsinkes 20 sekunder ved innsending.
Bruk på 60 minutter <<= 24 timer	Interaktiv avvisning	Brukerspørrte interaktive jobber avvises.
Bruk > 24 timer	Bakgrunnsavvisning	Alle forespørsler avvises.

Eksempel på utjevning og begrensningsgrenser

Her er et illustrerende eksempel på hvordan utjevning fungerer for én bakgrunnsoperasjon som brukte 1 CUHr (bruken tilsvarer 1 CU i 1 time). Bakgrunnsoperasjoner blir jevnet ut over 24 timer. En bakgrunnsoperasjons bidrag på et hvilket som helst tidspunkt er # CUHrs for operasjonen / # av CUHrs på SKU-nivå. For en F2 vil denne jobben bidra med 1 CUHr / 48CUhrs = ~2,1% til hvert tidspunkt. Virkningen på begrensningsgrensene på 10 minutter og 60 minutter er ~2,1%.

Her er detaljene som støtter eksemplet:

1 CUHr = 3600 CUer (1 CU * 60 minutter per time * 60 sekunder per minutt)

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

Siden 3600 CUs er jevnet over 24 timer, bidrar jobben med 3600 CUer/2880 tidspunkter til hvert 30-sekunders tidspunkt. Så det bidrar med 1,25 CUer per tidspunkt.

Begrensningsprosenten på 10 minutter er basert på de totale CU-ene som er tilgjengelige i løpet av de neste 10 minuttene med oppetid for kapasiteten.

En F2-kapasitet har 2 CU for hvert sekund (eller to CUer). I hvert tidspunkt har en F2 2 CUer * 30 sekunder = 60 CUer med databehandling.

Bidraget fra bakgrunnsjobben til et enkelt tidspunkt er 1,25 CUer/60 CUer = ~2,1% av et individuelt tidspunkt.

På 10 minutter har F2 2 CU * 60 sekunder * 10 minutter = 1200 CUer med databehandling.

Delen av bakgrunnsjobben som ble jevnet ut i de neste 10 minuttene av kapasiteten, er 1,25 CUer * 2 tidspunkter per minutt * 10 minutter = 25 CUer.

Så, 10-minutters begrensning prosent er 25 CUer / 1200 CUs = ~ 2,1%.

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

Selv om bakgrunnsoperasjonen brukte flere CUer enn det som er tilgjengelig i det neste tidsrommet på 10 minutter (det forbrukes seks ganger så mye), begrenses ikke F2-kapasiteten fordi de totale CUs-ene er jevnet ut 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 SKU støtter i ett enkelt tidspunkt, beregnes en overforbruk . Overforbruk beregnes etter at utjevning påføres. Hvis det er overforbruk som overskrider det tillatte 10-minutters begrensningsvinduet, blir de overførte CUer.

Beskyttelse mot overforbruk sikrer at kapasiteten ikke begrenses før det 10 minutter lange begrensningsvinduet er fullt. Den er utformet for å redusere hyppigheten av interaktive forsinkelser på grunn av midlertidige pigger i utnyttelse.

CU-ene for overføring brukes på hvert påfølgende tidspunkt. Hvis et tidspunkt ikke er fullt, reduserer de ubrukte CUs-ene CUs-beløpet for viderefør . Reduksjonen kalles gjenstående.

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

Overvåkingskapasitet for begrensning

Kapasitetsadministratorer kan konfigurere e-postvarsler som skal varsles når en kapasitet bruker 100% av de klargjorte CU-ressursene. 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. Når du bruker F SKU-er, kan du når som helst øke og redusere SKU-størrelsen manuelt i administratorinnstillingene, noe som gjør at du kan løse begrensningen når det er nødvendig.

Slik finner du ut at kapasitetsbegrensning forekommer

Når en kapasitet avviser forespørsler, ser brukerne bestemte feilkoder og feiltekst:

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

Merk

Treg ytelse hvis det ofte skyldes utformingen av et element. Bare noen ganger er treg ytelse på grunn av kapasitetsbegrensning.

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

1. Systemhendelser-tabellen på Databehandling-siden viser loggen over begrensningshendelser.
2. 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.

Hvis du vil slutte å begrense raskere, kan du imidlertid bruke strategiene som er oppført nedenfor.

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.
• Stans midlertidig, og fortsett deretter kapasiteten. 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.

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 ble sendt inn før begrensningen begynte, har lov til å kjøre til fullføring. Denne virkemåten gir deg forsikring om at operasjoner fullføres, selv under overspenninger 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 dataskjemaet OneLake for å gi spørringsresultatet. Hver av disse forespørslene danner en kjede.

Når det er en kjede av samtaler, er det en risiko for sammensatt begrensning, som er når begrensning brukes mer enn én gang på samme forespørsel. Stoffet har en innebygd sammensatt begrensningsbeskyttelse som reduserer sannsynligheten for sammensatt begrensning som oppstår. Arbeidsbelastninger kan velge å bruke denne beskyttelsen.

Når arbeidsbelastninger støtter sammensatt begrensningsbeskyttelse, begrenses en forespørsel bare é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 begrensning én gang for den første forespørselen den mottar i kjeden.

Følgende arbeidsbelastningsopplevelser støtter sammensatt begrensning:

• Semantiske modeller som kobler til andre semantiske modeller ved hjelp av Direct Query.
• DAX-spørringer fra paginerte rapporter til semantiske modeller.

Begrensningsvirkemåte er spesifikk for fabric-arbeidsbelastninger

Mens de fleste Fabric-produkter følger de tidligere nevnte begrensningsreglene, er det noen unntak.

Fabric-hendelsesstrømmer har for eksempel mange operasjoner som kan kjøre i årevis når de er startet. Begrensning av nye eventstream-operasjoner ville ikke være fornuftig, så i stedet reduseres mengden CU-ressurser som er tildelt for å holde strømmen åpen, til kapasiteten er i god stand igjen.

Et annet unntak er Sanntidsintelligens, som ikke ville vært i sanntid hvis operasjonene ble forsinket 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 virkemåten sikrer at brukerne kan fortsette å nyte sanntidsytelsen selv i perioder med høy etterspørsel.

På samme måte rapporteres nesten alle operasjoner i lagerkategorien som bakgrunn for å dra nytte av 24-timers utjevning av aktiviteten for å tillate 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 er begrenset annerledes. Når en interaktiv operasjon starter en kjede som inkluderer en bakgrunnsoperasjon, kan bakgrunnsoperasjonen bli underlagt begrensning som en interaktiv operasjon.

Interaktive klassifiseringer og bakgrunnsklassifiseringer for begrensning og utjevning

Noen administratorer legger kanskje merke til at operasjoner noen ganger klassifiseres som interaktive og jevnes ut som bakgrunn, eller omvendt. Dette skillet skjer fordi Fabrics begrensningssystemer må bruke begrensningsregler 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 scenarioer faller begrensningssystemet tilbake til å klassifisere operasjoner som bakgrunn, som er i brukerens beste interesse.

Spore overforbruk og avviste operasjoner

Du kan se om kapasiteten er overbelastet ved å se gjennom utnyttelsesdiagrammet i måledataappen for Microsoft Fabric Capacity Metrics. En pigg som går over linjen indikerer en overforbruk. Hvis du vil undersøke overforbruket ytterligere, driller du gjennom til tidspunktsiden. Du kan deretter se gjennom både interaktive operasjoner og bakgrunnsoperasjoner, og se hvilke som var ansvarlige for overforbrukene.

Siden utnyttelse over 100% ikke automatisk betyr begrensning, må du bruke begrensningsdiagrammet når du evaluerer overforbruk. Derfra kan du åpne en tabell som viser minutter til gjenstående, et diagram med legg til, gjenstående 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.

Hvis du vil vise en visuell logg over eventuell overutnyttelse av kapasitet, inkludert overføring, kumulativ og gjenstående utnyttelsesdata, går du til fanen Overages. Du kan endre den visuelle skalaen for overforbruk til å vise 10 minutter, 60 minutter og 24 timer.

Drilldown for Microsoft Fabric Capacity Metrics-appen gjør det mulig for administratorer å se operasjoner som ble avvist under en begrensningshendelse. Det er begrenset informasjon om disse operasjonene, da de aldri fikk lov til å starte. Administratoren kan se produktet, brukeren, operasjons-ID-en og tidspunktet forespørselen ble sendt inn. Når en forespørsel avvises, får sluttbrukere en feilmelding som ber dem om å prøve på nytt senere.

Fakturerbar og ikke-fakturerbar databehandling

Når du ser gjennom kapasitetsbruken i måledataappen for kapasitet, kan noen operasjoner faktureres, og andre kan ikke faktureres. Bare fakturerbare operasjoner er inkludert i begrensningsberegninger. Forhåndsvisningsfunksjoner kan generere operasjoner som ikke kan faktureres. Bruk ikke-fakturerbare operasjoner til å planlegge fremover, slik at kapasiteten er riktig størrelse 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.