Share via

Querylimieten

  • Artikel

Kusto is een ad-hoc query-engine die grote gegevenssets host en probeert te voldoen aan query's door alle relevante gegevens in het geheugen op te houden. Er is een inherent risico dat query's de serviceresources zonder grenzen monopoliseren. Kusto biedt verschillende ingebouwde beveiligingen in de vorm van standaardquerylimieten. Als u overweegt deze limieten te verwijderen, moet u eerst bepalen of u hiermee daadwerkelijk waarde krijgt.

Limiet voor gelijktijdigheid van aanvragen

Gelijktijdigheid van aanvragen is een limiet die een cluster oplegt aan meerdere aanvragen die tegelijkertijd worden uitgevoerd.

  • De standaardwaarde van de limiet is afhankelijk van de SKU waarop het cluster wordt uitgevoerd en wordt berekend als: Cores-Per-Node x 10.
    • Bijvoorbeeld, voor een cluster dat is ingesteld op D14v2 SKU, waarbij elke machine 16 vCores heeft, is 16 cores x10 = 160de standaardlimiet .
  • De standaardwaarde kan worden gewijzigd door het beleid voor de aanvraagfrequentielimiet van de default workloadgroep te configureren.
    • Het werkelijke aantal aanvragen dat gelijktijdig kan worden uitgevoerd op een cluster, is afhankelijk van verschillende factoren. De belangrijkste factoren zijn cluster-SKU, beschikbare resources van het cluster en gebruikspatronen. Het beleid kan worden geconfigureerd op basis van belastingtests die worden uitgevoerd op productieachtige gebruikspatronen.

Zie Optimaliseren voor hoge gelijktijdigheid met Azure Data Explorer voor meer informatie.

Limiet voor de grootte van de resultatenset (afkapping van resultaten)

Resultaatafkapping is een limiet die standaard is ingesteld voor de resultatenset die door de query wordt geretourneerd. Kusto beperkt het aantal records dat naar de client wordt geretourneerd tot 500.000 en de totale gegevensgrootte voor deze records tot 64 MB. Wanneer een van deze limieten wordt overschreden, mislukt de query met een 'gedeeltelijke queryfout'. Als u de totale gegevensgrootte overschrijdt, wordt er een uitzondering gegenereerd met het bericht:

The Kusto DataEngine has failed to execute a query: 'Query result set has exceeded the internal data size limit 67108864 (E_QUERY_RESULT_SET_TOO_LARGE).'

Het overschrijden van het aantal records mislukt met een uitzondering met de volgende tekst:

The Kusto DataEngine has failed to execute a query: 'Query result set has exceeded the internal record count limit 500000 (E_QUERY_RESULT_SET_TOO_LARGE).'

Er zijn verschillende strategieën om met deze fout om te gaan.

  • Verklein de grootte van de resultatenset door de query zo te wijzigen dat alleen interessante gegevens worden geretourneerd. Deze strategie is handig wanneer de eerste mislukte query te 'breed' is. Met de query worden bijvoorbeeld geen gegevenskolommen geprojected die niet nodig zijn.
  • Verklein de grootte van de resultatenset door de verwerking na de query, zoals aggregaties, te verplaatsen naar de query zelf. De strategie is handig in scenario's waarin de uitvoer van de query wordt doorgegeven aan een ander verwerkingssysteem en dat vervolgens andere aggregaties uitvoert.
  • Schakel over van query's naar het gebruik van gegevensexport wanneer u grote sets gegevens uit de service wilt exporteren.
  • Instrueer de service om deze querylimiet te onderdrukken met behulp van set de onderstaande instructies of vlaggen in clientaanvraageigenschappen.

Methoden voor het verkleinen van de grootte van de resultatenset die door de query wordt geproduceerd, zijn onder andere:

U kunt afkapping van resultaten uitschakelen met behulp van de notruncation aanvraagoptie. We raden u aan om nog steeds een beperking in te stellen.

Bijvoorbeeld:

set notruncation;
MyTable | take 1000000

Het is ook mogelijk om meer controle te hebben over afkapping van resultaten door de waarde van truncationmaxsize (maximale gegevensgrootte in bytes, standaard ingesteld op 64 MB) en truncationmaxrecords (maximum aantal records, standaard ingesteld op 500.000). Met de volgende query wordt bijvoorbeeld afkapping van resultaten ingesteld op 1105 records of 1 MB, afhankelijk van wat wordt overschreden.

set truncationmaxsize=1048576;
set truncationmaxrecords=1105;
MyTable | where User=="UserId1"

Als u de limiet voor afkapping van het resultaat verwijdert, betekent dit dat u van plan bent om bulkgegevens uit Kusto te verplaatsen.

U kunt de afkappingslimiet voor het resultaat verwijderen voor exportdoeleinden met behulp van de .export opdracht of voor latere aggregatie. Als u kiest voor latere aggregatie, kunt u overwegen om te aggregeren met behulp van Kusto.

Kusto biedt een aantal clientbibliotheken die oneindig grote resultaten kunnen verwerken door deze te streamen naar de aanroepende functie. Gebruik een van deze bibliotheken en configureer deze in de streamingmodus. Gebruik bijvoorbeeld de .NET Framework-client (Microsoft.Azure.Kusto.Data) en stel de streaming-eigenschap van de verbindingsreeks in op true of gebruik de aanroep ExecuteQueryV2Async() waarmee resultaten altijd worden gestreamd. Zie de toepassing HelloKustoV2 voor een voorbeeld van het gebruik van ExecuteQueryV2Async().

Mogelijk vindt u ook de voorbeeldtoepassing voor C#-streamingopname nuttig.

Resultaatafkapping wordt standaard toegepast, niet alleen op de resultatenstroom die naar de client wordt geretourneerd. Het wordt ook standaard toegepast op elke subquery die het ene cluster uitgeeft aan een ander cluster in een clusteroverschrijdende query, met vergelijkbare effecten.

Afkappingseigenschappen voor meerdere resultaten instellen

Het volgende is van toepassing bij het gebruik van set -instructies en/of bij het opgeven van vlaggen in eigenschappen van clientaanvragen.

  • Als notruncation is ingesteld en een van truncationmaxsize, truncationmaxrecordsof query_take_max_records ook is ingesteld, notruncation wordt genegeerd.
  • Als truncationmaxsizeen truncationmaxrecords /of query_take_max_records meerdere keren zijn ingesteld, is de lagere waarde voor elke eigenschap van toepassing.

Limiet voor geheugengebruik door queryoperators (E_RUNAWAY_QUERY)

Kusto beperkt het geheugen dat elke queryoperator kan gebruiken om te beschermen tegen 'runaway'-query's. Deze limiet kan worden bereikt door sommige queryoperators, zoals join en summarize, die worden uitgevoerd door belangrijke gegevens in het geheugen op te houden. De limiet is standaard 5 GB (per clusterknooppunt) en kan worden verhoogd door de aanvraagoptie maxmemoryconsumptionperiteratorin te stellen:

set maxmemoryconsumptionperiterator=68719476736;
MyTable | summarize count() by Use

Wanneer deze limiet is bereikt, wordt een gedeeltelijke queryfout verzonden met een bericht dat de tekst E_RUNAWAY_QUERYbevat.

The ClusterBy operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete E_RUNAWAY_QUERY.

The DemultiplexedResultSetCache operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The ExecuteAndCache operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The HashJoin operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The Sort operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The Summarize operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The TopNestedAggregator operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The TopNested operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

Als maxmemoryconsumptionperiterator meerdere keren is ingesteld, bijvoorbeeld in zowel clientaanvraageigenschappen als met behulp van een set -instructie, is de lagere waarde van toepassing.

Een extra limiet die een E_RUNAWAY_QUERY gedeeltelijke queryfout kan veroorzaken, is een limiet voor de maximale geaccumuleerde grootte van tekenreeksen die door één operator worden bewaard. Deze limiet kan niet worden overschreven door de bovenstaande aanvraagoptie:

Runaway query (E_RUNAWAY_QUERY). Aggregation over string column exceeded the memory budget of 8GB during evaluation.

Wanneer deze limiet wordt overschreden, is de relevante queryoperator waarschijnlijk een join, summarizeof make-series. Als u de limiet wilt omzeilen, moet u de query wijzigen om de willekeurige querystrategie te gebruiken. (Dit verbetert waarschijnlijk ook de prestaties van de query.)

In alle gevallen van is een extra optie (naast het verhogen van de limiet door het instellen van de aanvraagoptie en het wijzigen van E_RUNAWAY_QUERYde query om een willekeurige strategie te gebruiken) over te schakelen naar steekproeven. De twee onderstaande query's laten zien hoe u de steekproeven uitvoert. De eerste query is een statistische steekproef met behulp van een generator voor willekeurige getallen. De tweede query is deterministische steekproeven, die worden uitgevoerd door een hash te maken van een kolom uit de gegevensset, meestal een id.

T | where rand() < 0.1 | ...

T | where hash(UserId, 10) == 1 | ...

Geheugenlimiet per knooppunt

Het maximum aantal geheugen per query per knooppunt is een andere limiet die wordt gebruikt om te beschermen tegen 'runaway'-query's. Met deze limiet, vertegenwoordigd door de aanvraagoptie max_memory_consumption_per_query_per_node, wordt een bovengrens ingesteld voor de hoeveelheid geheugen die op één knooppunt voor een specifieke query kan worden gebruikt.

set max_memory_consumption_per_query_per_node=68719476736;
MyTable | ...

Als max_memory_consumption_per_query_per_node meerdere keren is ingesteld, bijvoorbeeld in zowel clientaanvraageigenschappen als met behulp van een set -instructie, is de lagere waarde van toepassing.

Als de query operatoren , joinof make-series gebruiktsummarize, kunt u de querystrategie shuffle gebruiken om de geheugenbelasting op één computer te verminderen.

Time-out voor uitvoering beperken

Servertime-out is een time-out aan de servicezijde die wordt toegepast op alle aanvragen. Time-out bij het uitvoeren van aanvragen (query's en beheeropdrachten) wordt op meerdere punten in de Kusto afgedwongen:

  • clientbibliotheek (indien gebruikt)
  • service-eindpunt dat de aanvraag accepteert
  • service-engine die de aanvraag verwerkt

De time-out is standaard ingesteld op vier minuten voor query's en 10 minuten voor beheeropdrachten. Deze waarde kan indien nodig worden verhoogd (maximaal één uur).

  • Verschillende clienthulpprogramma's ondersteunen het wijzigen van de time-out als onderdeel van hun algemene of per-verbindingsinstellingen. Gebruik bijvoorbeeld in Kusto.Explorer Extra>Opties* >Time-out voor queryserververbindingen>.
  • Programmatisch ondersteunen SDK's het instellen van de time-out via de servertimeout eigenschap. In .NET SDK wordt dit bijvoorbeeld gedaan via een clientaanvraageigenschap, door een waarde van het type System.TimeSpanin te stellen.

Notities over time-outs

  • Aan de clientzijde wordt de time-out toegepast vanaf de aanvraag die wordt gemaakt tot het moment waarop het antwoord bij de client binnenkomt. De tijd die nodig is om de nettolading terug te lezen op de client, wordt niet behandeld als onderdeel van de time-out. Dit is afhankelijk van hoe snel de aanroeper de gegevens uit de stream haalt.
  • Ook aan de clientzijde is de werkelijke time-outwaarde die wordt gebruikt iets hoger dan de servertime-outwaarde die door de gebruiker is aangevraagd. Dit verschil is om netwerklatenties mogelijk te maken.
  • Als u automatisch de maximaal toegestane time-out voor aanvragen wilt gebruiken, stelt u de eigenschap clientaanvraag in norequesttimeout op true.

Notitie

Zie Time-outlimieten instellen voor een stapsgewijze handleiding over het instellen van time-outs in de Azure Data Explorer-webinterface, Kusto.Explorer, Kusto.Cli, Power BI en wanneer u een SDK gebruikt.

Cpu-resourcegebruik van query's beperken

Met Kusto kunt u query's uitvoeren en net zoveel CPU-resources gebruiken als het cluster. Er wordt geprobeerd een fair round robin uit te voeren tussen query's als er meer dan één wordt uitgevoerd. Deze methode levert de beste prestaties op voor door query's gedefinieerde functies. Op andere momenten wilt u mogelijk de CPU-resources beperken die voor een bepaalde query worden gebruikt. Als u bijvoorbeeld een 'achtergrondtaak' uitvoert, kan het systeem hogere latenties tolereren om gelijktijdige inlinequery's hoge prioriteit te geven.

Kusto ondersteunt het opgeven van twee aanvraageigenschappen bij het uitvoeren van een query. De eigenschappen zijn query_fanout_threads_percent en query_fanout_nodes_percent. Beide eigenschappen zijn gehele getallen die standaard de maximumwaarde (100) hebben, maar die voor een specifieke query kunnen worden gereduceerd tot een andere waarde.

De eerste, query_fanout_threads_percent, bepaalt de fanout-factor voor threadgebruik. Wanneer deze eigenschap is ingesteld op 100%, wijst het cluster alle CPU's toe op elk knooppunt. Bijvoorbeeld 16 CPU's op een cluster dat is geïmplementeerd op Azure D14-knooppunten. Wanneer deze eigenschap is ingesteld op 50%, wordt de helft van de CPU's gebruikt, enzovoort. De getallen worden naar boven afgerond op een hele CPU, dus het is veilig om de eigenschapswaarde in te stellen op 0.

De tweede , query_fanout_nodes_percent, bepaalt hoeveel queryknooppunten in het cluster per subquerydistributiebewerking moeten worden gebruikt. Het werkt op een vergelijkbare manier.

Als query_fanout_nodes_percent of query_fanout_threads_percent meerdere keren zijn ingesteld, bijvoorbeeld in zowel clientaanvraageigenschappen als met behulp van een set -instructie, is de lagere waarde voor elke eigenschap van toepassing.

De complexiteit van query's beperken

Tijdens het uitvoeren van de query wordt de querytekst omgezet in een structuur van relationele operatoren die de query vertegenwoordigen. Als de diepte van de structuur een interne drempelwaarde overschrijdt, wordt de query als te complex beschouwd voor verwerking en mislukt de query met een foutcode. De fout geeft aan dat de structuur van relationele operators de limieten overschrijdt.

In de volgende voorbeelden ziet u veelvoorkomende querypatronen die ertoe kunnen leiden dat de query deze limiet overschrijdt en mislukt:

  • een lange lijst met binaire operatoren die aan elkaar zijn gekoppeld. Bijvoorbeeld:
T 
| where Column == "value1" or 
        Column == "value2" or 
        .... or
        Column == "valueN"

Voor dit specifieke geval herschrijft u de query met behulp van de in() operator.

T 
| where Column in ("value1", "value2".... "valueN")
  • een query met een samenvoegingsoperator die een te brede schemaanalyse uitvoert, met name omdat de standaardsmaak van samenvoeging is het retourneren van een 'outer' union-schema (wat betekent dat de uitvoer alle kolommen van de onderliggende tabel bevat).

De suggestie in dit geval is om de query te controleren en de kolommen te verminderen die door de query worden gebruikt.

Gerelateerde inhoud