Queryinterleaving

Van toepassing op: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Query interleaving is een tabelmodusconfiguratie van het systeem waarmee de prestaties van queries in situaties met hoge gelijktijdigheid kunnen worden verbeterd. De tabellaire Analysis Services-engine werkt standaard op een fifo-manier (first-in, first-out) met betrekking tot CPU. Als er met FIFO bijvoorbeeld een resource-intensieve en mogelijk trage opslag-enginequery wordt ontvangen, gevolgd door twee andere snelle query's, kunnen de snelle query's mogelijk geblokkeerd worden tot de dure query is voltooid. Dit gedrag wordt weergegeven in het volgende diagram, waarin Q1, Q2 en Q3 worden weergegeven als de respectieve query's, de duur en de CPU-tijd.

Door het interleaven van queries met een voorkeursbehandeling voor korte queries kunnen gelijktijdige queries CPU-resources delen, wat betekent dat snelle queries niet worden geblokkeerd door trage queries. De tijd die nodig is om alle drie de query's te voltooien, is nog steeds ongeveer hetzelfde, maar in ons voorbeeld worden Q2 en Q3 pas geblokkeerd tot het einde. Korte query-bias betekent dat snelle query's, gedefinieerd door hoeveel CPU een query tot dan toe heeft verbruikt, een groter deel van de resources kunnen krijgen toegewezen dan langlopende query's. In het volgende diagram worden Q2- en Q3-query's beschouwd als snel en meer CPU toegewezen dan Q1.

Query-interleaving is bedoeld om weinig of geen invloed te hebben op de prestaties van query's die geïsoleerd worden uitgevoerd; een enkele query kan nog steeds zoveel CPU verbruiken als met het FIFO-model.

Belangrijke overwegingen

Houd rekening met het volgende voordat u bepaalt of query-interleaving geschikt is voor uw scenario:

• Query-interleaving geldt alleen voor importmodellen. Dit heeft geen invloed op DirectQuery-modellen.
• Query-interleaving houdt alleen rekening met CPU die wordt gebruikt door query's van VertiPaq-opslagengines. Deze is niet van toepassing op bewerkingen van de formule-engine.
• Eén DAX-query kan resulteren in verschillende VertiPaq-opslagengine-opdrachten. Een DAX-query wordt als snel of traag beschouwd op basis van de CPU die wordt gebruikt door de query's van de opslagengine. De DAX-query is de maateenheid.
• Vernieuwingsbewerkingen worden standaard beveiligd tegen interleaving van query's. Langlopende vernieuwingsbewerkingen worden anders gecategoriseerd dan langlopende query's.

Configure

Als u query-interleaving wilt configureren, stelt u de eigenschap Threadpool\SchedulingBehavior in. Deze eigenschap kan worden opgegeven met de volgende waarden:

Waarde	Description
-1	Automatisch. De engine bepaalt het type wachtrij.
0 (standaard voor SSAS 2019)	Eerst in, eerst uit (FIFO).
1	Korte query-vooroordelen. De engine beperkt geleidelijk langlopende query's wanneer deze onder druk worden gezet ten gunste van snelle query's.
3 (standaard voor Azure AS, Power BI, SSAS 2022 en hoger)	Korte queryvoorkeuren voor snelle annulering. Verbetert de reactietijden van gebruikersquery's in scenario's met hoge gelijktijdigheid. Alleen van toepassing op Azure AS, Power BI, SSAS 2022 en hoger.

Op dit moment kan de eigenschap SchedulingBehavior alleen worden ingesteld met behulp van XMLA. In SQL Server Management Studio stelt het volgende XMLA-fragment de eigenschap SchedulingBehavior in op 1, korte query-bias.

<Alter AllowCreate="true" ObjectExpansion="ObjectProperties" xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
  <Object />
  <ObjectDefinition>
    <Server xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300" xmlns:ddl400="http://schemas.microsoft.com/analysisservices/2012/engine/400" xmlns:ddl400_400="http://schemas.microsoft.com/analysisservices/2012/engine/400/400" xmlns:ddl500="http://schemas.microsoft.com/analysisservices/2013/engine/500" xmlns:ddl500_500="http://schemas.microsoft.com/analysisservices/2013/engine/500/500">
      <ID>myserver</ID>
      <Name>myserver</Name>
      <ServerProperties>
        <ServerProperty>
          <Name>ThreadPool\SchedulingBehavior</Name>
          <Value>1</Value>
        </ServerProperty>
      </ServerProperties>
    </Server>
  </ObjectDefinition>
</Alter>

Belangrijk

Er is een herstart van de serverinstantie nodig. In Azure Analysis Services moet u de server onderbreken en vervolgens hervatten, waardoor de server effectief opnieuw wordt opgestart.

Aanvullende eigenschappen

In de meeste gevallen is SchedulingBehavior de enige eigenschap die u moet instellen. De volgende aanvullende eigenschappen hebben standaardwaarden die in de meeste scenario's met korte query-bias moeten werken, maar ze kunnen indien nodig worden gewijzigd. De volgende eigenschappen hebben geen effect , tenzij query-interleaving is ingeschakeld door de eigenschap SchedulingBehavior in te stellen.

ReservedComputeForFastQueries - Hiermee stelt u het aantal gereserveerde logische kernen in voor snelle query's. Alle query's worden snel beschouwd totdat ze vervallen omdat ze een bepaalde hoeveelheid CPU hebben verbruikt. ReservedComputeForFastQueries is een geheel getal tussen 0 en 100. De standaardwaarde is 75.

De maateenheid voor ReservedComputeForFastQueries is het percentage kernen. Een waarde van 80 op een server met 20 kernen probeert bijvoorbeeld 16 kernen te reserveren voor snelle query's (terwijl er geen vernieuwingsbewerkingen worden uitgevoerd). ReservedComputeForFastQueries rondt af naar het dichtstbijzijnde gehele aantal kernen. Het is raadzaam om deze eigenschapswaarde niet in te stellen onder de 50. Dit komt doordat snelle query's kunnen worden benadeeld en dit indruist tegen het algehele ontwerp van de functie.

DecayIntervalCPUTime : een geheel getal dat de CPU-tijd weergeeft in milliseconden die een query doorgeeft voordat deze vergaat. Als het systeem onder CPU-druk staat, zijn de achtergebleven query's beperkt tot de resterende kernen die niet zijn gereserveerd voor snelle query's. De standaardwaarde is 60.000. Dit vertegenwoordigt 1 minuut CPU-tijd, niet verstreken kalendertijd.

ReservedComputeForProcessing : hiermee stelt u het aantal gereserveerde logische kernen in voor elke bewerking (gegevensvernieuwing). De eigenschapswaarde is een geheel getal tussen 0 en 100, met een standaardwaarde van 75 uitgedrukt. De waarde vertegenwoordigt een percentage van de kernen die worden bepaald door de eigenschap ReservedComputeForFastQueries. Een waarde van 0 (nul) betekent dat verwerkingsbewerkingen onderhevig zijn aan dezelfde interleavinglogica voor query's als query's, zodat ze kunnen worden vervallen.

Hoewel er geen verwerkingsbewerkingen worden uitgevoerd, heeft ReservedComputeForProcessing geen effect. Bijvoorbeeld, met de waarde 80, ReservedComputeForFastQueries op een server met 20 kernen behoudt 16 kernen voor snelle query's. Met de waarde 75 reserveert ReservedComputeForProcessing vervolgens 12 van de 16 kernen voor vernieuwingsbewerkingen, waardoor 4 voor snelle query's blijft terwijl verwerkingsbewerkingen worden uitgevoerd en CPU verbruikt. Zoals beschreven in de sectie Verouderde query's hieronder, worden de resterende 4 kernen, (niet gereserveerd voor snelle query's of verwerkingsbewerkingen), toch gebruikt voor snelle query's en verwerking als ze inactief zijn.

Deze aanvullende eigenschappen bevinden zich onder het eigenschappenknooppunt ResourceGovernance . In SQL Server Management Studio stelt het volgende XMLA-fragment de eigenschap DecayIntervalCPUTime in op een waarde lager dan standaard:

<Alter AllowCreate="true" ObjectExpansion="ObjectProperties" xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
  <Object />
  <ObjectDefinition>
    <Server xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300" xmlns:ddl400="http://schemas.microsoft.com/analysisservices/2012/engine/400" xmlns:ddl400_400="http://schemas.microsoft.com/analysisservices/2012/engine/400/400" xmlns:ddl500="http://schemas.microsoft.com/analysisservices/2013/engine/500" xmlns:ddl500_500="http://schemas.microsoft.com/analysisservices/2013/engine/500/500">
      <ID>myserver</ID>
      <Name>myserver</Name>
      <ServerProperties>
        <ServerProperty>
          <Name>ResourceGovernance\DecayIntervalCPUTime</Name>
          <Value>15000</Value>
        </ServerProperty>
      </ServerProperties>
    </Server>
  </ObjectDefinition>
</Alter>

Verouderde queries

De beperkingen die in deze sectie worden beschreven, zijn alleen van toepassing als het systeem onder CPU-druk valt. Als één query bijvoorbeeld de enige is die op een bepaald moment in het systeem wordt uitgevoerd, kan deze alle beschikbare kernen verbruiken, ongeacht of deze is verlopen of niet.

Voor elke query zijn mogelijk veel opslagenginetaken vereist. Wanneer een kern in de pool voor vervallen query's beschikbaar komt, controleert de scheduler de oudste lopende query op basis van de verstreken kalenderperiode om te zien of deze al zijn Maximum Core Entitlement (MCE) heeft gebruikt. Als het antwoord nee is, wordt de volgende taak uitgevoerd. Zo ja, dan wordt de volgende oudste query geëvalueerd. De query MCE wordt bepaald door hoeveel vervalintervallen deze al heeft gebruikt. Voor elk gebruikte vervalinterval wordt de MCE verminderd op basis van het algoritme dat wordt weergegeven in de onderstaande tabel. Dit gaat door totdat de query is voltooid, een time-out optreedt of de MCE wordt gereduceerd tot één kern.

In het volgende voorbeeld heeft het systeem 32 kernen en wordt de CPU van het systeem onder druk gezet.

ReservedComputeForFastQueries is 60 (60%).

• 20 kernen (19,2 naar boven afgerond) zijn gereserveerd voor snelle queries.
• De resterende 12 kernen worden toegewezen voor vervallen query's.

DecayIntervalCPUTime is 60.000 (1 minuut CPU-tijd).

De levenscyclus van een query kan als volgt verlopen, zolang deze niet verloopt of voltooid raakt:

Fase	Toestand	Uitvoering/planning	MCE
0	Snel	De MCE heeft 20 kernen (gereserveerd voor snelle query’s). De query wordt in FIFO-volgorde uitgevoerd met betrekking tot andere snelle queries op de 20 gereserveerde kernen. De vervalperiode van 1 minuut CPU-tijd is opgebruikt.	20 = MIN(32/2˄0, 20)
1	Rot	De MCE is ingesteld op 12 kernen (12 resterende kernen die niet zijn gereserveerd voor snelle query's). Taken worden uitgevoerd op basis van beschikbaarheid tot MCE. Vervalinterval van 1 minuut CPU-tijd wordt verbruikt.	12 = MIN(32/2˄1, 12)
2	Rot	De MCE is ingesteld op 8 kernen (kwartaal van 32 totaal aantal kernen). Taken worden uitgevoerd op basis van beschikbaarheid tot aan MCE. De afbraakperiode van 1 minuut CPU-tijd is verbruikt.	8 = MIN(32/2˄2, 12)
3	Rot	De MCE is ingesteld op 4 kernen. Taken worden uitgevoerd op basis van beschikbaarheid tot aan MCE. Een vervalinterval van 1 minuut CPU-tijd is verbruikt.	4 = MIN(32/2^3, 12)
4	Rot	De MCE is ingesteld op 2 kernen. Taken worden uitgevoerd op basis van beschikbaarheid tot MCE. Een vervalinterval van 1 minuut CPU-tijd is verbruikt.	2 = MIN(32/2˄4, 12)
5	Rot	De MCE is ingesteld op 1 kern. Taken worden uitgevoerd op basis van beschikbaarheid tot MCE. Vervalinterval is niet van toepassing omdat de query zijn laagste punt heeft bereikt. Geen verder verval omdat minimaal 1 kern wordt bereikt.	1 = MIN(32/2˄5, 12)

Als het systeem onder CPU-druk staat, wordt aan elke query geen kernen meer toegewezen dan de MCE. Als alle kernen momenteel worden gebruikt door query's binnen hun respectieve MCE's, wachten andere query's totdat kernen beschikbaar zijn. Naarmate er kernen beschikbaar komen, wordt de oudste geautoriseerde query op basis van de verstreken tijd op de kalender geselecteerd. De MCE is een restrictie bij druk; het garandeert niet op enig moment een bepaald aantal kernen.

Zie ook

Servereigenschappen in Analysis Services