Querylimieten

Van toepassing op: ✅Microsoft Fabric✅Azure Data Explorer✅Azure Monitor✅Microsoft Sentinel-

Kusto is een ad-hocquery-engine die als host fungeert voor grote gegevenssets 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 servicebronnen zonder grenzen in beslag zullen maken. Kusto biedt verschillende ingebouwde beveiligingen in de vorm van standaardquerylimieten. Als u deze limieten overweegt te verwijderen, moet u eerst bepalen of u hiermee daadwerkelijk waarde krijgt.

Limiet voor gelijktijdigheid van aanvragen

gelijktijdigheid van aanvragen is een limiet die wordt opgelegd aan verschillende aanvragen die tegelijkertijd worden uitgevoerd.

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

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

afkapping van resultaten is een limiet die standaard is ingesteld voor de resultatenset die door de query wordt geretourneerd. Kusto beperkt het aantal records dat aan de client wordt geretourneerd tot 500.000en 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 voor het oplossen van deze fout.

• Verklein de grootte van de resultatenset door de query te wijzigen zodat alleen interessante gegevens worden geretourneerd. Deze strategie is handig wanneer de eerste mislukte query te breed is. Met de query worden bijvoorbeeld gegevenskolommen die niet nodig zijn, niet geprojected.
• Verklein de grootte van de resultatenset door postqueryverwerking, zoals aggregaties, naar de query zelf te verplaatsen. De strategie is handig in scenario's waarin de uitvoer van de query wordt ingevoerd in een ander verwerkingssysteem en 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 instructies die hieronder worden vermeld of vlaggen in eigenschappen van clientaanvragen.

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

• Gebruik de operator samenvatten groep en aggregeren over vergelijkbare records in de queryuitvoer. U kunt een aantal kolommen steekproefen met behulp van de take_any aggregatiefunctie.
• Gebruik een operator om de query-uitvoer te samplen.
• Gebruik de subtekenreeksfunctie om brede vrije-tekstkolommen te knippen.
• Gebruik de projectoperator om een onintervalerende kolom uit de resultatenset te verwijderen.

U kunt het afkappen van resultaten uitschakelen met behulp van de optie notruncation aanvraag. We raden u aan dat er nog een vorm van beperking is ingesteld.

Bijvoorbeeld:

set notruncation;
MyTable | take 1000000

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

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

Het verwijderen van de limiet voor het afkappen van resultaten betekent dat u bulkgegevens uit Kusto wilt verplaatsen.

U kunt de limiet voor het afkappen van resultaten verwijderen voor exportdoeleinden met behulp van de opdracht .export of voor latere aggregatie. Als u later aggregatie kiest, kunt u overwegen om te aggregeren met Behulp van Kusto.

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

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

Afkapping van resultaten wordt standaard toegepast, niet alleen op de resultaatstroom die wordt geretourneerd naar de client.

Deze wordt ook standaard toegepast op elke subquery die de ene Eventhouse uitgeeft aan een andere Eventhouse-query in een cross-Eventhouse-query, met vergelijkbare effecten.

Eigenschappen voor het afkappen van meerdere resultaten instellen

Het volgende geldt voor 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, wordt notruncation genegeerd.
• Als truncationmaxsize, worden truncationmaxrecords en/of query_take_max_records meerdere keren ingesteld: de lagere waarde voor elke eigenschap is van toepassing.

Limiet voor geheugen dat wordt gebruikt 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 aanzienlijke gegevens in het geheugen te bewaren. De limiet is standaard 5 GB (per knooppunt) en kan worden verhoogd door de aanvraagoptie in te stellen maxmemoryconsumptionperiterator:

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

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

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 eigenschappen van clientaanvragen en het gebruik van een set-instructie, is de lagere waarde van toepassing.

De maximaal ondersteunde waarde voor deze aanvraagoptie is 32212254720 (30 GB).

Een extra limiet die een E_RUNAWAY_QUERY gedeeltelijke queryfout kan activeren, is een limiet voor de maximumgrootte 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 query te gebruiken strategie. (Dit is waarschijnlijk ook het verbeteren van de prestaties van de query.)

In alle gevallen van E_RUNAWAY_QUERYis een extra optie (behalve het verhogen van de limiet door de aanvraagoptie in te stellen en de query te wijzigen in een willekeurige strategie) over te schakelen naar steekproeven. In de twee onderstaande query's ziet u hoe u de steekproeven kunt uitvoeren. De eerste query is een statistische steekproef met behulp van een generator voor willekeurige getallen. De tweede query is deterministische steekproeven, uitgevoerd door een hash van een kolom uit de gegevensset, meestal een bepaalde id.

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

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

Limiet voor geheugen per knooppunt

Maximaal geheugen per query per knooppunt is een andere limiet die wordt gebruikt om te beschermen tegen runaway-query's. Deze limiet, vertegenwoordigd door de aanvraagoptie max_memory_consumption_per_query_per_node, stelt een bovengrens in 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 eigenschappen van clientaanvragen en het gebruik van een set-instructie, is de lagere waarde van toepassing.

Als de query gebruikmaakt van summarize, joinof make-series operators, kunt u de query strategie gebruiken om de geheugenbelasting op één machine 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 actieve aanvragen (query's en beheeropdrachten) wordt afgedwongen op meerdere punten in de Kusto:

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

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

• Verschillende clienthulpprogramma's ondersteunen het wijzigen van de time-out als onderdeel van hun globale of per-verbindingsinstellingen. Gebruik bijvoorbeeld in Kusto.Explorer Tools>Options* >Connections>Query Server Timeout.
• Programmatisch bieden SDK's ondersteuning voor het instellen van de time-out via de eigenschap servertimeout. 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 op basis van de aanvraag die wordt gemaakt totdat 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 hangt af van hoe snel de beller de gegevens uit de stream haalt.
• Ook aan de clientzijde is de werkelijke time-outwaarde die wordt gebruikt iets hoger dan de time-outwaarde van de server die door de gebruiker is aangevraagd. Dit verschil is om netwerklatenties mogelijk te maken.
• Als u automatisch de maximaal toegestane aanvraagtime-out wilt gebruiken, stelt u de eigenschap van de clientaanvraag in norequesttimeout op true.

Limiet voor het cpu-resourcegebruik van query's

Met Kusto kunt u query's uitvoeren en alle beschikbare CPU-resources gebruiken die de database heeft. Er wordt geprobeerd een eerlijke round robin uit te voeren tussen query's als er meer dan één wordt uitgevoerd. Deze methode levert de beste prestaties op voor querygedefinieerde 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 kunnen worden verkleind voor een specifieke query naar een andere waarde.

De eerste, query_fanout_threads_percent, bepaalt de fanoutfactor voor threadgebruik. Wanneer deze eigenschap 100%is ingesteld, worden alle CPU's op elk knooppunt toegewezen. Bijvoorbeeld 16 CPU's die zijn geïmplementeerd op Azure D14-knooppunten. Wanneer deze eigenschap is ingesteld op 50%, worden de helft van de CPU's gebruikt, enzovoort. De getallen worden 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 van de queryknooppunten 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 eigenschappen van clientaanvragen en het gebruik van een set-instructie, is de lagere waarde voor elke eigenschap van toepassing.

Limiet voor querycomplexiteit

Tijdens het uitvoeren van de query wordt de querytekst omgezet in een structuur van relationele operators die de query vertegenwoordigen. Als de structuurdiepte een interne drempelwaarde overschrijdt, wordt de query als te complex beschouwd voor verwerking en mislukt deze 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 ervoor kunnen zorgen dat de query deze limiet overschrijdt en mislukt:

• een lange lijst met binaire operators 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 operator in().

T
| where Column in ("value1", "value2".... "valueN")

• een query met een samenvoegoperator die te brede schemaanalyse uitvoert, met name dat de standaardsmaak van samenvoeging het 'outer' samenvoegschema retourneert (wat betekent dat uitvoer alle kolommen van de onderliggende tabel bevat).

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

Verwante inhoud

• best practices voor query's