Les på engelsk

Del via


Stoffbegrensningspolicyen

Begrensning oppstår når en leierkapasitet bruker mer kapasitetsressurser enn den har kjøpt. 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 lynrask ytelse til sine kunder ved å gi operasjoner tilgang til flere kapasitetsenhetsressurser (CU) enn det som er allokert til kapasiteten. Oppgaver som kan ta flere minutter å fullføre på andre plattformer, kan fullføres på bare sekunder på Fabric. For å unngå å straffe brukere når driftsbelastningen øker, jevner Fabric ut eller gjennomsnitter CU-bruken av en operasjon over minst fem minutter, og enda lenger for høy CU-bruk, men korte kjøretidsforespørsler. Denne virkemåten sikrer at du kan nyte konsekvent rask ytelse uten å oppleve begrensning.

For bakgrunnsoperasjoner som har lange kjøretider og bruker tunge CU-belastninger, jevner Fabric ut CU-bruken over en 24-timers periode. Utjevning eliminerer behovet for at dataforskere og databaseadministratorer bruker tid på å opprette jobbtidsplaner for å spre CU-belastning over dagen for å hindre at kontoer fryser. Med 24-timers CU-utjevning kan planlagte jobber kjøre samtidig uten å forårsake noen pigger når som helst i løpet av dagen, og du kan nyte konsekvent rask ytelse uten å kaste bort tid på å administrere jobbtidsplaner.

Operasjoner om bord begrenses ikke

Når en kapasitet angir en begrenset tilstand, påvirker den bare operasjoner som er forespurt etter at kapasiteten har begynt å begrenses. 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.

Begrensningsutløsere og begrensningsfaser

Etter utjevning kan noen kontoer fortsatt oppleve økninger i CU-bruk i perioder med høy rapportering. For å hjelpe til med å administrere disse toppene kan administratorer konfigurere e-postvarsler som skal varsles når en kapasitet bruker 100 % av de klargjorte CU-ressursene. Dette mønsteret er en indikasjon på at kapasiteten kan dra nytte av belastningsfordeling, og administratoren bør vurdere å øke SKU-størrelsen. Det er viktig å være oppmerksom på at for F SKU-er kan du øke og redusere dem manuelt når som helst i administratorinnstillingene. Men selv når en kapasitet opererer på sitt fulle CU-potensial, bruker ikke Fabric begrensning. Denne virkemåten sikrer at brukerne har konsekvent rask ytelse uten å oppleve forstyrrelser.

Den første fasen av begrensningen begynner når en kapasitet har brukt alle tilgjengelige CU-ressurser de neste 10 minuttene. Hvis du for eksempel kjøpte 10 kapasitetsenheter og deretter brukte 50 enheter per minutt, ville du opprettet en overføring på 40 enheter per minutt. Etter to og et halvt minutt, ville du ha akkumulert en bæreforward av 100 enheter, lånt fra fremtidige vinduer. På dette punktet hvor all kapasitet allerede er oppbrukt de neste 10 minuttene, starter Fabric sitt første nivå av begrensning, og alle nye interaktive operasjoner forsinkes med 20 sekunder ved innsending. Hvis overføringen når en hel time, blir interaktive forespørsler avvist, men planlagte bakgrunnsoperasjoner fortsetter å kjøre. Hvis kapasiteten akkumuleres hele 24 timer med viderefør, fryses hele kapasiteten til overføringen betales.

Fremtidig jevnet forbruk

Obs!

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.

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.

Reduksjon av kapasitetsbruk for bæreforward

Hver gang en kapasitet har inaktiv kapasitet, betaler systemet ned bærenivåene.

Hvis du har 100 CU minutter og en carryforward på 200 CU minutter, og du ikke har noen operasjoner kjører, tar det to minutter for deg å betale ned bæreforward. I dette eksemplet er ikke systemet begrenset, da det er to minutter med viderebæring. Begrensningsforsinkelser begynner ikke før 10 minutter med viderebæring er akkumulert.

Hvis du trenger å betale ned bæringen raskere, kan du øke SKU-størrelsen midlertidig for å generere mer inaktiv kapasitet som brukes på håndbagasjen.

Begrensningsvirkemåten er spesifikk for Fabric

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 ignorerer Sanntids intelligens den første fasen av begrensning med 20-sekunders forsinkelser på 10 minutter med carryforward og venter til avvisningsfasen på 60 minutter med carryforward for å 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 rekke operasjoner som er begrenset annerledes. Dette kan gjøre at en bakgrunnsoperasjon blir underlagt begrensning som en interaktiv operasjon.

Interaktive klassifiseringer og bakgrunnsklassifiseringer for begrensning og utjevning

Microsoft Fabric deler operasjoner inn i to typer, interaktive og bakgrunner. Du finner beskrivelser av disse og forskjellene mellom dem i stoffoperasjoner.

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. Utjevning skjer etter at jobben har begynt å kjøre, og CU-forbruk kan måles.

Begrensningssystemer forsøker å kategorisere operasjoner nøyaktig ved innsending, men noen ganger kan klassifiseringen av operasjonen endres etter at begrensning er brukt. Når operasjonen begynner å kjøre, blir mer detaljert informasjon om forespørselen tilgjengelig. I tvetydige scenarioer prøver begrensningssystemer å feile på siden av klassifiseringsoperasjoner 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 overbelastning. Hvis du vil undersøke overbelastningen ytterligere, driller du gjennom til tidspunktsiden. Deretter kan du se gjennom både interaktive operasjoner og bakgrunnsoperasjoner, og se hvilke som var ansvarlige for å overbelaste kapasiteten. Du kan også bestemme når overbelastningshendelsene fant sted.

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.

Animasjon som viser ekstraheringsalternativet for et valgt tidspunkt.

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. Carryforward tar bare hensyn til fakturerbare operasjoner.

Animasjon som viser overforbruk over tid.

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.

Handlinger du kan utføre for å gjenopprette fra overbelastningssituasjoner

Når kapasiteten er begrenset til det punktet den er frosset, får brukerne en feilmelding hvis handlingen krever databehandlingsressurser for stoff. Feilen kan for eksempel si at Kan ikke laste inn modell på grunn av at kapasitetsgrensene er nådd. I slike tilfeller kan du bruke disse strategiene til å gjenopprette kapasiteten fra den frosne tilstanden.

  • Vent til overbelastningstilstanden er over før du utsteder nye forespørsler.
  • Oppgrader SKU-en for en F-kapasitet.
  • Stans/fortsett en F-kapasitet midlertidig.
  • Autoskaler en P-kapasitet.
  • Flytt lavere prioritet eller overforbruk arbeidsområder ut av kapasiteten.