Stoffbegrensningspolicyen

  • Artikkel

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 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, kan oppleve 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 CU-ressurser (kapasitetsenheter) enn det som er tildelt 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 5 minutter, og enda lenger for høye CU, 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 forsikringen om at operasjoner fullføres, selv under CU-overspenninger.

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 den klargjorte CU-en. 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. Dette 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 enheter cu og deretter brukte 50 enheter per minutt, ville du opprettet en videresending av 40 enheter per minutt. Etter to og et halvt minutt, ville du ha akkumulert en videresending av 100 enheter, lånt fra fremtidige vinduer. På dette punktet hvor kapasiteten allerede har brukt opp all kapasitet de neste 10 minuttene, starter Fabric sitt første nivå av begrensning, og alle nye interaktive operasjoner forsinkes med 20 sekunder ved innsending. Hvis videresendingen når en hel time, blir interaktive forespørsler avvist, men planlagte operasjoner i bakgrunnen fortsetter å kjøre. Hvis kapasiteten akkumulerer hele 24 timer med videresending, fryses hele kapasiteten til videresendingen betales.

Fremtidig jevnet forbruk

Merk

Microsoft prøver å forbedre kundens fleksibilitet ved bruk av tjenesten, samtidig som de balanserer behovet for å administrere kundens kapasitetsbruk. 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 videresending

Hver gang en kapasitet har inaktiv kapasitet, betaler systemet ned overføringsnivåene.

Hvis du har 100 CU-minutter og en viderefør på 200 CU-minutter, og du ikke har noen operasjoner i gang, tar det to minutter før du betaler videre. I dette eksemplet er ikke systemet begrenset, da det er to minutter med videresending. Begrensningsforsinkelser vil ikke begynne før det er på 10 minutter med videresending.

Hvis du må betale ned videreføringen raskere, kan du øke SKU-størrelsen midlertidig for å generere mer inaktiv kapasitet som brukes på videresendingen.

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øres i årevis når de er startet. Begrensning av nye hendelsesstrømoperasjoner ville ikke være fornuftig, så i stedet reduseres mengden CU som er tildelt for å holde strømmen åpen, til kapasiteten er i god stand igjen.

Et annet unntak er Sanntidsanalyse, som ikke ville vært i sanntid hvis operasjonene ble forsinket med 20 sekunder. Som et resultat ignorerer Sanntidsanalyse den første fasen av begrensning med 20-sekunders forsinkelser ved 10 minutters videreføring og venter til avvisningsfasen på 60 minutter med videresending 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 begrenses annerledes. Dette kan gjøre at en bakgrunnsoperasjon blir 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 utjevnede 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 en operasjon 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.

Spor avviste operasjoner

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. Sluttbrukere får en feilmelding når en forespørsel blir avvist som ber dem om å prøve på nytt senere.

Relatert innhold