Prokládání dotazů

platí pro: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Prokládání dotazů je konfigurace systému v režimu tabulkové prezentace, která může zlepšit výkon dotazů ve scénářích s vysokou úrovní souběžnosti. Tabulkový modul Analysis Services ve výchozím nastavení pracuje způsobem první dovnitř, první ven (FIFO) ve vztahu k procesoru. Pokud je například přijat jeden dotaz na úložišťový modul, který je náročný na prostředky a pravděpodobně pomalý, a po něm následují dva jinak rychlé dotazy, tyto rychlé dotazy mohou potenciálně zablokovat a čekat na dokončení náročného dotazu. Toto chování je znázorněno v následujícím diagramu, který zobrazuje Q1, Q2 a Q3 jako příslušné dotazy, jejich dobu trvání a čas procesoru.

Prokládání dotazů s biasem na krátké dotazy umožňuje souběžným dotazům sdílet prostředky procesoru, což znamená, že rychlé dotazy nejsou blokovány kvůli pomalým dotazům. Doba potřebná k dokončení všech tří dotazů je stále stejná, ale v našem příkladu Q2 a Q3 nejsou zablokované až do konce. Zvýhodnění krátkých dotazů znamená, že rychlé dotazy, definované podle toho, kolik procesoru každý dotaz již spotřeboval v daném okamžiku, mohou být přiděleny vyšší podíly prostředků než dlouhotrvající dotazy. V následujícím diagramu se dotazy Q2 a Q3 považují za rychlé a přidělují více procesorů než Q1.

Prokládání dotazů má za cíl mít malý nebo žádný dopad na výkon dotazů, které běží izolovaně; Jeden dotaz může stále spotřebovávat tolik procesoru, kolik to dělá s modelem FIFO.

Důležité aspekty

Před určením, jestli je prokládání dotazů pro váš scénář správné, mějte na paměti následující skutečnosti:

• Prokládání dotazů platí jenom pro modely importu. Nemá vliv na modely DirectQuery.
• Prokládání dotazů bere v úvahu pouze využití procesoru při provádění dotazů úložným strojem VertiPaq. Nevztahuje se na operace výpočetního motoru.
• Jeden dotaz DAX může vést k několika dotazům na modul úložiště VertiPaq. Dotaz DAX se považuje za rychlý nebo pomalý podle procesorem spotřebovaného dotazy úložného modulu. Dotaz DAX funguje jako měrná jednotka.
• Operace aktualizace jsou ve výchozím nastavení chráněné před prokládáním dotazů. Dlouhotrvající operace aktualizace jsou rozdělené do kategorií odlišně od dlouhotrvajících dotazů.

Konfigurujte

Chcete-li konfigurovat prokládání dotazů, nastavte vlastnost Threadpool\SchedulingBehavior. Tuto vlastnost lze zadat s následujícími hodnotami:

Hodnota	Description
-1	Automatic. Modul zvolí typ fronty.
0 (výchozí hodnota pro SSAS 2019)	První dovnitř, první ven (FIFO).
1	Krátká zaujatost dotazu. Motor postupně omezuje dlouhotrvající dotazy během zátěže ve prospěch rychlých dotazů.
3 (výchozí nastavení pro Azure AS, Power BI, SSAS 2022 a novější)	Zkreslení krátkých dotazů s rychlým zrušením Vylepšuje dobu odezvy dotazů uživatelů ve scénářích s vysokou souběžností. Platí jenom pro Azure AS, Power BI, SSAS 2022 a novější.

V tuto chvíli lze vlastnost SchedulingBehavior nastavit pouze pomocí XMLA. V aplikaci SQL Server Management Studio nastaví následující fragment kódu XMLA vlastnost SchedulingBehavior na hodnotu 1, krátká odchylka dotazu.

<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>

Důležité

Vyžaduje se restartování instance serveru. Ve službě Azure Analysis Services je nutné server pozastavit a znovu spustit, čímž dojde k efektivnímu restartu.

Další vlastnosti

Ve většině případů je SchedulingBehavior jedinou vlastností, kterou potřebujete nastavit. Následující vlastnosti mají výchozí hodnoty, které by měly ve většině scénářů fungovat s krátkou skresleností dotazů, ale v případě potřeby je můžete změnit. Následující vlastnosti nemají žádný vliv , pokud není povoleno prokládání dotazu nastavením vlastnosti SchedulingBehavior.

ReservedComputeForFastQueries – nastaví počet vyhrazených logických jader pro rychlé dotazy. Všechny dotazy se považují za rychlé, dokud se nevyčerpají, protože spotřebují určitou část CPU. ReservedComputeForFastQueries je celé číslo od 0 do 100. Výchozí hodnota je 75.

Měrná jednotka pro ReservedComputeForFastQueries je procento jader. Například hodnota 80 na serveru s 20 jádry se pokusí rezervovat 16 jader pro rychlé dotazy (zatímco se neprovádí žádné operace aktualizace). ReservedComputeForFastQueries zaokrouhlí nahoru na nejbližší celý počet jader. Doporučuje se, abyste tuto hodnotu vlastnosti nenastavili pod 50. Je to proto, že rychlé dotazy mohou být omezeny a je to v rozporu s celkovým návrhem funkce.

DecayIntervalCPUTime – celé číslo představující čas procesoru v milisekundách, který dotaz stráví, než se degraduje. Pokud je systém pod tlakem procesoru, dotazy s nižší prioritou jsou omezeny na zbývající jádra, která nejsou vyhrazena pro rychlé dotazy. Výchozí hodnota je 60 000. Představuje 1 minutu času procesoru, nikoli uplynulý kalendářní čas.

ReservedComputeForProcessing – nastaví počet vyhrazených logických jader pro každou operaci zpracování (aktualizace dat). Hodnota vlastnosti je celé číslo od 0 do 100 s výchozí hodnotou 75 vyjádřenou. Hodnota představuje procento jader určených vlastností ReservedComputeForFastQueries. Hodnota 0 (nula) znamená, že operace zpracování podléhají stejné logikě prokládání dotazů jako dotazy, takže může dojít k rozkladu.

Pokud nejsou prováděny žádné operace zpracování, funkce ReservedComputeForProcessing nemá žádný vliv. Například s hodnotou 80, ReservedComputeForFastQueries na serveru s 20 jádry vyhrazuje 16 jader pro rychlé dotazy. S hodnotou 75 si ReservedComputeForProcessing pak vyhradí 12 z 16 jader pro operace aktualizace a 4 pro rychlé dotazy, zatímco operace zpracování běží a spotřebovávají procesor. Jak je popsáno v části Rozpadané dotazy níže, zbývající 4 jádra (nejsou vyhrazena pro rychlé dotazy nebo operace zpracování), budou nadále použita pro rychlé dotazy a zpracování v případě nečinnosti.

Tyto další vlastnosti se nacházejí v uzlu vlastností ResourceGovernance . V sadě SQL Server Management Studio nastaví následující příklad fragment kódu XMLA vlastnost DecayIntervalCPUTime na hodnotu nižší než výchozí:

<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>

Zastaralé dotazy

Omezení popsaná v této části platí pouze v případě, že je systém pod tlakem procesoru. Například jeden dotaz, pokud je jediným spuštěným v systému v daném okamžiku, může spotřebovat všechna dostupná jádra bez ohledu na to, jestli se rozpadla nebo ne.

Každý dotaz může vyžadovat mnoho úloh modulu úložiště. Jakmile bude k dispozici jádro ve fondu pro rozkládající se dotazy, plánovač zkontroluje nejstarší spuštěný dotaz na základě uplynulého kalendářního času a zjistí, jestli už vyčerpal svůj maximální nárok na jádro (MCE). Pokud ne, provedena bude další úloha. Pokud ano, vyhodnotí se další nejstarší dotaz. Dotaz MCE je určen podle počtu intervalů rozkladu, které už byly použity. Pro každý použitý interval rozkladu se MCE sníží na základě algoritmu uvedeného v následující tabulce. To pokračuje, dokud se dotaz neskončí, vyprší časový limit nebo se MCE sníží na jedno jádro.

V následujícím příkladu má systém 32 jader a procesor systému je pod tlakem.

ReservedComputeForFastQueries je 60 (60%).

• Pro rychlé dotazy je rezervovaných 20 jader (19,2 zaokrouhleno nahoru).
• Zbývajících 12 jader se přidělí pro vypršené dotazy.

DecayIntervalCPUTime je 60 000 (1 minuta času procesoru).

Životní cyklus dotazu může být následující, pokud se nevyprší časový limit nebo se nedokončí:

Etapa	Stav	Spouštění/plánování	MCE
0	Rychlé	MCE má 20 jader (určeno pro rychlé dotazy). Dotaz se provádí způsobem FIFO s ohledem na další rychlé dotazy napříč 20 rezervovanými jádry. Byl využit interval 1 minuty času procesoru.	20 = MIN(32/2˄0, 20)
1	Zkažený	MCE je nastaveno na 12 jader (12 zbývajících jader není vyhrazeno pro rychlé dotazy). Úlohy se spouštějí na základě dostupnosti podle požadavků MCE. Interval rozpadu o délce 1 minuty času procesoru byl vyčerpán.	12 = MIN(32/2˄1; 12)
2	Zkažený	MCE je nastaveno na 8 jader (čtvrtina 32 celkových jader). Úlohy jsou spouštěny na základě dostupnosti až do MCE. Interval 1 minuty času procesoru je vyčerpán.	8 = MIN(32/2˄2; 12)
3	Zkažený	MCE je nastaveno na 4 jádra. Úlohy se spouští na základě dostupnosti až do MCE. Jednominutový interval rozpadu času procesoru byl vyčerpán.	4 = MIN(32/2˄3; 12)
4	Zkažený	MCE je nastaveno na 2 jádra. Úlohy se spouští na základě dostupnosti až do MCE. Jednominutový interval rozpadu času procesoru byl vyčerpán.	2 = MIN(32/2˄4; 12)
5	Zkažený	MCE je nastaveno na 1 jádro. Úlohy se spouští na základě dostupnosti až do MCE. Interval útlumu se nepoužije, protože dotaz dosáhl konečného stavu. Od dosažení minimálního počtu 1 jader už nedojde k žádnému dalšímu rozkladu.	1 = MIN(32/2˄5; 12)

Pokud je systém pod tlakem procesoru, každý dotaz bude přiřazen maximálně počet jader odpovídající jeho MCE. Pokud jsou všechna jádra aktuálně používána dotazy v rámci příslušných MCE, ostatní dotazy čekají, dokud nebudou jádra k dispozici. Jakmile budou k dispozici jádra, vyzvedne se nejstarší oprávněný dotaz na základě uplynulého kalendářního času. MCE je tlakový uzávěr; nezaručuje pevný počet jader kdykoli.

Viz také

Vlastnosti serveru ve službě Analysis Services