Interfoliazione di query

Articolo
12/23/2023

Si applica a: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

L'interleaving delle query è una configurazione del sistema in modalità tabulare che può migliorare le prestazioni delle query negli scenari di concorrenza elevata. Per impostazione predefinita, il motore tabulare di Analysis Services funziona in modo first-in first-out (FIFO) per quanto riguarda la CPU. Con FIFO, ad esempio, se viene ricevuta una risorsa e una query del motore di archiviazione lenta e quindi seguita da due query altrimenti veloci, le query veloci possono potenzialmente essere bloccate in attesa del completamento della query costosa. Questo comportamento viene illustrato nel diagramma seguente, che mostra Q1, Q2 e Q3 come query, la relativa durata e l'ora della CPU.

Prima di tutto, prima di tutto

L'interleaving delle query con distorsioni di query brevi consente alle query simultanee di condividere le risorse della CPU, il che significa che le query veloci non vengono bloccate dietro query lente. Il tempo necessario per completare tutte e tre le query è ancora uguale, ma nell'esempio Q2 e Q3 non vengono bloccati fino alla fine. Il pregiudizio della query breve significa query veloci, definite dalla quantità di CPU che ogni query ha già utilizzato in un determinato momento può essere allocata una percentuale superiore di risorse rispetto alle query a esecuzione prolungata. Nel diagramma seguente, le query Q2 e Q3 vengono considerate veloci e allocate più CPU rispetto a Q1.

Distorsione della query breve

L'interleaving delle query è destinato a avere un impatto sulle prestazioni ridotte o nulle sulle query eseguite in isolamento; una singola query può comunque utilizzare la CPU come fa con il modello FIFO.

Considerazioni importanti

Prima di determinare se l'interleaving delle query è adatto per lo scenario, tenere presente quanto segue:

L'interleaving delle query si applica solo per i modelli di importazione. Non influisce sui modelli DirectQuery.
L'interleaving delle query considera solo la CPU utilizzata dalle query del motore di archiviazione VertiPaq. Non si applica alle operazioni del motore di formula.
Una singola query DAX può comportare più query del motore di archiviazione VertiPaq. Una query DAX viene considerata veloce o lenta in base alla CPU utilizzata dalle query del motore di archiviazione. La query DAX è l'unità di misura.
Le operazioni di aggiornamento sono protette per impostazione predefinita dall'interleaving delle query. Le operazioni di aggiornamento a esecuzione prolungata vengono classificate in modo diverso alle query a esecuzione prolungata.

Configurare

Per configurare l'interleaving delle query, impostare la proprietà Threadpool\SchedulingBehavior . Questa proprietà può essere specificata con i valori seguenti:

Valore	Descrizione
-1	Automatico. Il motore sceglierà il tipo di coda.
0 (impostazione predefinita per SSAS 2019)	Prima di tutto (FIFO).
1	Distorsione della query breve. Il motore limita gradualmente le query a esecuzione prolungata quando sotto pressione a favore delle query veloci.
3 (impostazione predefinita per Azure AS, Power BI, SSAS 2022 e versioni successive)	Distorsione della query breve con annullamento rapido. Migliora i tempi di risposta delle query utente negli scenari di concorrenza elevata. Si applica solo ad Azure AS, Power BI, SSAS 2022 e versioni successive.

In questo momento, la proprietà SchedulingBehavior può essere impostata solo tramite XMLA. In SQL Server Management Studio, il frammento di codice XMLA seguente imposta la proprietà SchedulingBehavior su 1, con distorsione della query breve.

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

Importante

È necessario riavviare l'istanza del server. In Azure Analysis Services è necessario sospendere e quindi riprendere il server, riavviare in modo efficace.

Proprietà aggiuntive

Nella maggior parte dei casi, SchedulingBehavior è l'unica proprietà da impostare. Le proprietà aggiuntive seguenti hanno impostazioni predefinite che devono funzionare nella maggior parte degli scenari con distorsioni di query brevi, tuttavia possono essere modificate se necessario. Le proprietà seguenti non hanno alcun effetto a meno che l'interleaving delle query non sia abilitata impostando la proprietà SchedulingBehavior.

ReservedComputeForFastQueries : imposta il numero di core logici riservati per le query veloci . Tutte le query vengono considerate veloci finché non decadono perché hanno usato una certa quantità di CPU. ReservedComputeForFastQueries è un intero compreso tra 0 e 100. Il valore predefinito è 75.

L'unità di misura per ReservedComputeForFastQueries è la percentuale di core. Ad esempio, un valore pari a 80 su un server con 20 core tenta di riservare 16 core per query veloci (mentre non vengono eseguite operazioni di aggiornamento). ReservedComputeForFastQueries si arrotonda fino al numero intero più vicino di core. È consigliabile non impostare questo valore di proprietà inferiore a 50. Ciò è dovuto al fatto che le query veloci potrebbero essere private e sono in contrasto con la progettazione complessiva della funzionalità.

DecadimentoIntervalCPUTime : intero che rappresenta il tempo della CPU in millisecondi trascorso da una query prima del decadimento. Se il sistema è sotto pressione cpu, le query decadite sono limitate ai core rimanenti non riservati alle query veloci. Il valore predefinito è 60.000. Questo rappresenta 1 minuto di tempo della CPU, non trascorso il tempo del calendario.

ReservedComputeForProcessing : imposta il numero di core logici riservati per ogni operazione di elaborazione (aggiornamento dati). Il valore della proprietà è un intero compreso tra 0 e 100, con un valore predefinito pari a 75 espresso. Il valore rappresenta una percentuale dei core determinati dalla proprietà ReservedComputeForFastQueries. Un valore pari a 0 (zero) significa che le operazioni di elaborazione sono soggette alla stessa logica di interleaving di query, quindi può essere decaduta.

Mentre non vengono eseguite operazioni di elaborazione, ReservedComputeForProcessing non ha alcun effetto. Ad esempio, con un valore pari a 80, ReservedComputeForFastQueries in un server con 20 core riserva 16 core per query veloci. Con un valore pari a 75, ReservedComputeForProcessing riserva quindi 12 dei 16 core per le operazioni di aggiornamento, lasciando 4 per le query veloci durante l'esecuzione e l'utilizzo della CPU. Come descritto nella sezione Query decadite di seguito, i 4 core rimanenti (non riservati alle query veloci o alle operazioni di elaborazione) verranno comunque usati per query veloci ed elaborazioni se inattive.

Queste proprietà aggiuntive si trovano nel nodo Proprietà ResourceGovernance . In SQL Server Management Studio il frammento di codice XMLA di esempio seguente imposta la proprietà DecayIntervalCPUTime su un valore inferiore al valore predefinito:

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

Query decadite

I vincoli descritti in questa sezione si applicano solo se il sistema è sotto pressione della CPU. Ad esempio, una singola query, se è l'unica in esecuzione nel sistema in un determinato momento, può utilizzare tutti i core disponibili indipendentemente dal fatto che sia decaduto o meno.

Ogni query può richiedere molti processi del motore di archiviazione. Quando un core nel pool per le query decadite diventa disponibile, l'utilità di pianificazione verificherà la query in esecuzione meno recente in base al tempo trascorso del calendario per verificare se è già stato usato il diritto massimo core (MCE). Se no, il processo successivo viene eseguito. In caso affermativo, viene valutata la query meno recente successiva. La query MCE è determinata dal numero di intervalli di decadimento già usati. Per ogni intervallo di decadimento usato, l'ambiente di gestione delle chiavi viene ridotto in base all'algoritmo illustrato nella tabella seguente. Ciò continua fino a quando la query non viene completata, il timeout o l'ambiente di gestione dei dati viene ridotto a un singolo core.

Nell'esempio seguente il sistema ha 32 core e la CPU del sistema è sotto pressione.

ReservedComputeForFastQueries è 60 (60%).

20 core (19,2 arrotondati) è riservato alle query veloci.
I 12 core rimanenti vengono allocati per le query decadite.

DecayIntervalCPUTime è 60.000 (1 minuto di tempo della CPU).

Il ciclo di vita di una query può essere il seguente, purché non venga completato o non completato:

Fase	Stato	Esecuzione/pianificazione	MCE
0	Veloce	McE è 20 core (riservato per le query veloci). La query viene eseguita in modo FIFO rispetto ad altre query veloci tra i 20 core riservati. L'intervallo di decadimento di 1 minuto di tempo della CPU viene usato.	20 = MIN(32/2˄0, 20)
1	Decaduto	McE è impostato su 12 core (12 core rimanenti non riservati alle query veloci). I processi vengono eseguiti in base alla disponibilità fino a MCE. L'intervallo di decadimento di 1 minuto di tempo della CPU viene usato.	12 = MIN(32/2˄1, 12)
2	Decaduto	McE è impostato su 8 core (trimestre di 32 core totali). I processi vengono eseguiti in base alla disponibilità fino a MCE. L'intervallo di decadimento di 1 minuto di tempo della CPU viene usato.	8 = MIN(32/2˄2, 12)
3	Decaduto	McE è impostato su 4 core. I processi vengono eseguiti in base alla disponibilità fino a MCE. L'intervallo di decadimento di 1 minuto di tempo della CPU viene usato.	4 = MIN(32/2˄3, 12)
4	Decaduto	McE è impostato su 2 core. I processi vengono eseguiti in base alla disponibilità fino a MCE. L'intervallo di decadimento di 1 minuto di tempo della CPU viene usato.	2 = MIN(32/2˄4, 12)
5	Decaduto	McE è impostato su 1 core. I processi vengono eseguiti in base alla disponibilità fino a MCE. L'intervallo di decadimento non si applica perché la query è stata inferiore. Nessun ulteriore decadimento perché viene raggiunto un minimo di 1 core.	1 = MIN(32/2˄5, 12)

Se il sistema è sotto pressione CPU, ogni query verrà assegnata senza più core rispetto al relativo MCE. Se tutti i core sono attualmente usati dalle query all'interno dei rispettivi MCEs, altre query attendeno fino a quando i core non diventano disponibili. Poiché i core diventano disponibili, viene recuperata la query con diritto meno recente in base al tempo trascorso del calendario. L'MCE è un limite sotto pressione; non garantisce il numero di core in qualsiasi momento.

Vedi anche

Proprietà server in Analysis Services