Fabric-begrænsningspolitikken

Begrænsning sker, når en lejers kapacitet forbruger flere kapacitetsressourcer, end den har købt. For meget begrænsning kan resultere i en forringet slutbrugeroplevelse. En Fabric-lejer kan oprette flere kapaciteter og tildele arbejdsområder til en bestemt kapacitet til fakturering og størrelse.

Begrænsning anvendes på kapacitetsniveau, hvilket betyder, at mens én kapacitet eller et sæt arbejdsområder kan have reduceret ydeevne på grund af overbelastning, kan andre kapaciteter fortsætte med at køre normalt. I tilfælde, hvor funktioner som OneLake-artefakter produceres i én kapacitet og forbruges af en anden, bestemmer forbrugskapacitetens begrænsningstilstand, om kald til artefaktet begrænses.

Balance mellem ydeevne og pålidelighed

Fabric er designet til at levere lynhurtigt ydeevne til sine kunder ved at give handlinger adgang til flere CU-ressourcer (Capacity Units), end der er allokeret til kapaciteten. Opgaver, der kan tage flere minutter at udføre på andre platforme, kan udføres på få sekunder på Fabric. For at undgå at straffe brugerne, når driftsmæssige belastninger bølge, Fabric glatter eller gennemsnit CU brugen af en operation over mindst 5 minutter, og endnu længere for høj CU, men kort kørsel anmodninger. Denne funktionsmåde sikrer, at du kan få en konsekvent hurtig ydeevne uden at opleve begrænsning.

For baggrundshandlinger, der har lange kørselstider og forbruger tunge CU-belastninger, udjævner Fabric deres CU-forbrug over en 24-timers periode. Udjævning fjerner behovet for, at dataforskere og databaseadministratorer bruger tid på at oprette jobplaner for at sprede CU-belastningen over hele dagen for at forhindre konti i at fryse. Med 24-timers CU-udjævning kan planlagte job køre samtidigt uden at forårsage stigninger når som helst i løbet af dagen, og du kan nyde den konstant hurtige ydeevne uden at spilde tid på at administrere jobplaner.

In-flight operationer er ikke begrænset

Når en kapacitet går i en begrænset tilstand, påvirker den kun de handlinger, der anmodes om, efter at kapaciteten er begyndt at begrænse. Alle handlinger, herunder langvarige handlinger, der blev sendt, før begrænsningen begyndte, har tilladelse til at køre til fuldførelse. Denne funktionsmåde giver dig sikkerhed for, at handlingerne er fuldført, selv under CU-stigninger.

Throttle-udløsere og throttle-faser

Efter udjævning kan nogle konti stadig opleve stigninger i CU-forbruget under spidsbelastningsrapporteringstider. For at hjælpe med at administrere disse spidsbelastninger kan administratorer konfigurere mailbeskeder, der skal underrettes, når en kapacitet forbruger 100 % af den klargjorte CU. Dette mønster er en indikation af, at kapaciteten kan drage fordel af justering af belastning, og administratoren bør overveje at øge SKU-størrelsen. Det er vigtigt at bemærke, at for F-SKU'er kan du manuelt øge og reducere dem når som helst i administratorindstillingerne. Men selvom en kapacitet opererer på sit fulde CU-potentiale, anvender Fabric ikke begrænsning. Dette sikrer, at brugerne konsekvent har en hurtig ydeevne uden at opleve afbrydelser.

Den første fase af begrænsningen begynder, når en kapacitet har brugt alle sine tilgængelige CU-ressourcer i de næste 10 minutter. Hvis du f.eks. har købt 10 enheder cu og derefter forbrugt 50 enheder pr. minut, skal du oprette en fremførsel på 40 enheder pr. minut. Efter to og et halvt minut, ville du have akkumuleret en fremførsel af 100 enheder, lånt fra fremtidige vinduer. På dette tidspunkt, hvor kapaciteten allerede har opbrugt al kapacitet i de næste 10 minutter, starter Fabric sit første niveau af begrænsning, og alle nye interaktive handlinger forsinkes med 20 sekunder efter indsendelsen. Hvis overførsel når en hel time, afvises interaktive anmodninger, men planlagte handlinger i baggrunden fortsætter med at køre. Hvis kapaciteten akkumuleres med hele 24 timers fremførsel, fastfryses hele kapaciteten, indtil fremførslerne betales.

Fremtidigt udjævningsforbrug

Bemærk

Microsoft forsøger at forbedre kundens fleksibilitet i forbindelse med brugen af tjenesten, samtidig med at behovet for at administrere kundens kapacitetsforbrug opvejes. Derfor kan Microsoft ændre eller opdatere Fabric-begrænsningspolitikken.

Brug Politikgrænser Effekt af platformspolitikoplevelse
Forbrug <= 10 minutter Beskyttelse mod overage Job kan forbruge 10 minutters fremtidig kapacitetsanvendelse uden begrænsning.
10 minutter < forbrug <= 60 minutter Interaktiv forsinkelse Brugeropsøgte interaktive job forsinkes 20 sekunder ved indsendelse.
60 minutter < forbrug <= 24 timer Interaktiv afvisning Brugeropsøgte interaktive job afvises.
Forbrug > 24 timer Afvisning i baggrunden Alle anmodninger afvises.

Reducering af kapacitetsforbrug frem

Når en kapacitet har inaktiv kapacitet, betaler systemet de fremadrettede niveauer.

Hvis du har 100 CU minutter og en fremførsel på 200 CU minutter, og du ikke har nogen operationer kørende, tager det to minutter for dig at betale din fremførsel. I dette eksempel begrænses systemet ikke, da der er 2 minutters fremførsel. Begrænsningsforsinkelser begynder først, når der er gået 10 minutter.

Hvis du har brug for at betale din fremførsel hurtigere, kan du midlertidigt øge din SKU-størrelse for at generere mere inaktiv kapacitet, der anvendes på din overførsel.

Begrænsningsadfærd er specifik for Fabric

Selvom de fleste Fabric-produkter følger de tidligere nævnte begrænsningsregler, er der nogle undtagelser.

Fabric-hændelsesstrømme har f.eks. mange handlinger, der kan køre i årevis, når de er startet. Det ville ikke give mening at begrænse nye hændelsesstrømme, så i stedet reduceres mængden af CU, der er allokeret til at holde strømmen åben, indtil kapaciteten er i god stand igen.

En anden undtagelse er Realtidsanalyse, som ikke ville være i realtid, hvis handlingerne blev forsinket med 20 sekunder. Derfor ignorerer analyse i realtid den første fase af begrænsningen med 20 sekunders forsinkelser med 10 minutters fremførsel og venter til afvisningsfasen med 60 minutters fremførsel for at begynde begrænsningen. Denne funktionsmåde sikrer, at brugerne fortsat kan nyde godt af ydeevnen i realtid, selv i perioder med høj efterspørgsel.

På samme måde rapporteres næsten alle handlinger i kategorien Warehouse som baggrund for at drage fordel af 24-timers udjævning af aktiviteter for at give mulighed for de mest fleksible forbrugsmø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 streng af handlinger, der er begrænset forskelligt. Dette kan gøre en baggrundshandling underlagt begrænsning som en interaktiv handling.

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

Nogle administratorer vil muligvis bemærke, at handlinger nogle gange er klassificeret som interaktive og udjævnede som baggrund eller omvendt. Denne skelnen sker, fordi Fabrics begrænsningssystemer skal anvende begrænsningsregler, før en anmodning begynder at køre. Udjævning sker, når jobbet er begyndt at køre, og CU-forbrug kan måles.

Begrænsningssystemer forsøger at kategorisere handlinger nøjagtigt efter indsendelse, men nogle gange kan klassificeringen af en handling ændres, efter at begrænsningen er blevet anvendt. Når handlingen begynder at køre, bliver mere detaljerede oplysninger om anmodningen tilgængelige. I tvetydige scenarier forsøger begrænsningssystemer at fejle på siden af at klassificere handlinger som baggrund, hvilket er i brugerens bedste interesse.

Spor afviste handlinger

Detailudledning i appen Microsoft Fabric Capacity Metrics giver administratorer mulighed for at se handlinger, der blev afvist under en begrænsningshændelse. Der er begrænsede oplysninger om disse handlinger, da de aldrig fik lov til at starte. Administratoren kan se produktet, brugeren, handlings-id'et og tidspunktet, hvor anmodningen blev sendt. Slutbrugerne modtager en fejlmeddelelse, når en anmodning afvises, og de bliver bedt om at prøve igen senere.

  • Installér appen Microsoft Fabric capacity metrics for at overvåge Fabric-kapaciteter.