Delen via

Grafiekprestaties bewaken in Microsoft Fabric

Opmerking

Deze functie is momenteel beschikbaar als openbare preview-versie. Deze preview wordt geleverd zonder een service level agreement en wordt niet aanbevolen voor productieworkloads. Bepaalde functies worden mogelijk niet ondersteund of hebben mogelijk beperkte mogelijkheden. Zie Aanvullende gebruiksvoorwaarden voor Microsoft Azure Previews voor meer informatie.

De grafiekprestaties in Microsoft Fabric zijn afhankelijk van de grafiekgrootte, de complexiteit van het model, querypatronen en de beschikbaarheid van capaciteit. Leer wat u kunt controleren, hoe u knelpunten kunt identificeren en welke acties u moet uitvoeren wanneer vernieuwingstaken traag zijn of query's geen resultaten retourneren zoals verwacht.

Zie Grafiekworkloads bewaken voor het bijhouden van de status van een eenvoudige vernieuwingstaak. Zie GQL-queryprestaties optimaliseren voor optimalisatietechnieken voor GQL-query's.

Vereiste voorwaarden

Controleer voordat u begint of u:

Factoren die van invloed zijn op grafiekprestaties

Verschillende onderling verbonden factoren zijn van invloed op grafiekprestaties. Diagnosticeer langzame updates en langzame query's door te begrijpen wat ze veroorzaakt.

Grafiekgrootte en -complexiteit

  • Grafieken met meer dan 500 miljoen knooppunten en randen leiden tot instabiele prestaties. Zie Huidige beperkingen voor de volledige lijst met limieten.
  • Elke extra knooppunttype, randtype en eigenschap wordt toegevoegd aan de gegevens die tijdens een vernieuwing worden geladen. Het verwijderen van ongebruikte knooppunttypen, randtypen en eigenschappen van uw model vermindert de vernieuwingstijd.
  • Dichte grafieken (veel randen per knooppunt) verhogen de kosten voor doorkruising. Als de meeste knooppunten verbinding maken met duizenden andere knooppunten, worden query's die meerdere hops doorlopen duur.

Kenmerken van brongegevens

  • De grafiek leest rechtstreeks uit de lakehouse-tabellen in OneLake. Het opnemen van grote brontabellen met veel kolommen duurt langer.
  • Als uw brontabellen kolommen bevatten die u niet nodig hebt in de grafiek, verwijdert u deze eigenschappen tijdens het modelleren van grafieken. Elke eigenschap wordt toegevoegd aan de gegevens die worden gelezen tijdens het vernieuwen en de geheugenvoetafdruk van de doorzoekbare grafiek.

Query-patronen

  • Query's die veel hops doorlopen, volledige knooppunten retourneren (RETURN *) of niet-gebonden resultatensets produceren, verbruiken meer resources en duren langer om uit te voeren.
  • Filters op patroonniveau, smalle projecties en LIMIT clausules verminderen het werk dat de queryengine uitvoert. Zie GQL-queryprestaties optimaliseren voor specifieke technieken.

Capaciteit en gelijktijdigheid

  • Graafvernieuwingstaken en query's verbruiken pooled Fabric-capaciteitseenheden (CA's). Andere workloads in dezelfde capaciteit concurreren voor deze resources.
  • Als vernieuwingstaken consistent traag zijn, controleert u of andere workloads met een hoog verbruik tegelijkertijd worden uitgevoerd met behulp van de microsoft Fabric Capacity Metrics-app.

Vernieuwingsprestaties bewaken

Gebruik de Bewakingshub om bij te houden hoe lang het vernieuwen van grafieken duurt en of ze slagen of mislukken. Zie Grafieken workloads voor stapsgewijze instructies voor toegang tot de Bewakingshub.

Trage vernieuwingen identificeren

Vergelijk vernieuwingsduur in de loop van de tijd om een basislijn voor uw grafiek tot stand te brengen. Een vernieuwing die aanzienlijk langer duurt dan normaal kan duiden op:

  • Groei van brongegevens: de onderliggende lakehouse-tabellen zijn gegroeid en er worden meer gegevens toegevoegd voor grafiekverwerking.
  • Toename van de complexiteit van het model: er zijn nieuwe knooppunttypen, randtypen of eigenschappen toegevoegd aan het model.
  • Capaciteitsdruk: andere workloads verbruiken een groter deel van de beschikbare capaciteit.

Reageren op vernieuwingsfouten

Vernieuwingstaken voor grafieken kunnen mislukken wanneer ze de time-out van 20 minuten overschrijden. Voor grote grafen kan deze time-out tot wel één keer per week een fout veroorzaken. Als een vernieuwing mislukt:

  1. Open de Bewakingshub en zoek de mislukte vernieuwingstaak.
  2. Selecteer de taak om foutdetails en tijdsinstellingen weer te geven.
  3. Als de fout een time-out was, probeert u het opnieuw. De volgende vernieuwing slaagt meestal. Als er herhaaldelijk time-outs optreden, verkleint u de grafiekgrootte door ongebruikte knooppunttypen, randtypen of eigenschappen te verwijderen.
  4. Als de fout is veroorzaakt door een configuratiefout, opent u uw grafenmodel en controleert u of toewijzingen van knooppunt- en randtypen, id-kolommen en vreemd-sleutelkolommen juist zijn.

Zie Probleemoplossing en veelgestelde vragen voor meer informatie over probleemoplossing.

Prestaties van query monitoren

Tijdens de preview zijn afzonderlijke GQL-querygegevens niet beschikbaar in de Bewakingshub. Gebruik in plaats daarvan deze benaderingen om queryprestaties te begrijpen en te verbeteren.

Bekijk het querygedrag in de Code-editor

Wanneer u een GQL-query uitvoert in de Code-editor, bekijkt u het volgende:

  • Reactietijd: hoe lang het duurt voordat de query resultaten retourneert. Trage queries omvatten doorgaans diepe doorkruisingen, niet-gebonden overeenkomsten of grote resultsets.
  • Resultaatgrootte: Grote resultatensets (naderend op de afkappingslimiet van 64 MB) geven aan dat de query strengere grenzen of filters nodig heeft. Als de resultaten worden afgekapt, voegt u LIMIT, FILTER, of WHERE clausules toe om de uitvoer te verfijnen.
  • Lege resultaten na een geslaagde vernieuwing: deze situatie betekent meestal dat de configuratie van het grafiekmodel niet overeenkomt met de onderliggende gegevens. Controleer of de toewijzingen van het knooppunttype naar de juiste brontabellen en -kolommen wijzen.

Veelvoorkomende problemen met queryprestaties en -acties

Symptoom Waarschijnlijke oorzaak Action
Query duurt meer dan een paar seconden Diepe doorkruising (hoog aantal hops) of ontbrekende filters Voeg clausules op patroonniveau WHERE toe, reduceer hopbereik en pas LIMIT toe.
Query retourneert geen resultaten Onjuiste configuratie van knooppunt- of edge-type of lege brontabellen Controleer of er modeltoewijzingen zijn en controleer of er brongegevens bestaan.
Queryresultaten worden ingekort Resultaatset overschrijdt 64 MB Smalle projecties met specifieke eigenschappen in plaats van RETURN *, en voeg toe LIMIT.
Aggregaties zijn traag of instabiel Resultatenset overschrijdt 128 MB voor aggregatie Voeg filters toe om tussenliggende resultaten te verminderen voordat GROUP BY.
Query verloopt (limiet van 20 minuten) Niet-gebonden multihop-traversal op een compacte grafiek Gebruik TRAIL om het opnieuw bezoeken van randen te voorkomen, strikte hopgrenzen instellen, en LIMIT toe te voegen.

Zie GQL-queryprestaties optimaliseren voor gedetailleerde strategieën voor queryoptimalisatie.

Capaciteitsgebruik bijhouden

Gebruik de microsoft Fabric Capacity Metrics-app om te begrijpen hoe grafiekworkloads van invloed zijn op uw totale capaciteitsverbruik. De app helpt u bij het volgende:

  • Vergelijk het capaciteitsgebruik tussen graafvernieuwingstaken en andere Fabric-workloads.
  • Identificeer tijdsperioden waarin de capaciteitsdruk het vernieuwen van grafieken kan vertragen.
  • Bepaal wanneer u uw capaciteit omhoog of omlaag wilt schalen op basis van gebruikstrends.

Zie Install the Microsoft Fabric Capacity Metrics app voor meer informatie.

Samenvatting van best practices voor prestaties

  • De juiste grootte van uw model: Verwijder knooppunttypen, randtypen en eigenschappen die u niet nodig hebt. Kleinere modellen worden sneller vernieuwd en verbruiken minder geheugen.
  • Filter vroeg, projecteer smal: gebruik clausules op patroonniveau WHERE en retourneer alleen de eigenschappen die u nodig hebt. Vermijd RETURN *.
  • Beperk uw resultaten: Toepassen LIMIT op query's met hoge kardinaliteit. Houd de resultaten goed onder de afkappingsdrempel van 64 MB.
  • Houd traversals ondiep: gebruik het kleinste hopbereik dat uw scenario toestaat. Gebruik TRAIL om redundante paden in dichte grafen te voorkomen.
  • Vernieuwingstrends bewaken: stel de duur van een basislijnvernieuwing vast en onderzoek wanneer vernieuwingen aanzienlijk afwijken.
  • Controleer de capaciteit tijdens vertragingen: gebruik de app Capacity Metrics om te bepalen of de capaciteitsdruk de oorzaak is.

Verwante inhoud

  • Last updated on