Intercalazione delle query

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

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

L'intercalazione delle query con preferenziazione di query brevi consente alle query simultanee di condividere le risorse della CPU, il che significa che le query veloci non vengono bloccate dalle 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. Per distorsione a favore delle query brevi si intende che le query veloci, definite dalla quantità di CPU già consumata in un dato momento, possono ricevere una proporzione di risorse maggiore rispetto alle query con esecuzione prolungata. Nel diagramma seguente le query Q2 e Q3 vengono considerate veloci e allocate più CPU rispetto a Q1.

L'interfoliazione delle query è progettata per avere un impatto minimo o nullo sulle prestazioni delle query eseguite in isolamento; una singola query può comunque consumare la stessa quantità di CPU utilizzata con il modello FIFO.

Considerazioni importanti

Prima di determinare se l'interfoliazione delle query sia adatta al tuo scenario, considera quanto segue:

• L'interfoliazione delle query si applica solo per i modelli di importazione. Non influisce sui modelli DirectQuery.
• L'interfoliazione delle query considera solo la CPU utilizzata dal motore di archiviazione di VertiPaq. Non si applica alle operazioni del motore di formule.
• Una singola query DAX può generare 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 di default dall'interfoliazione delle query. Le operazioni di aggiornamento a esecuzione prolungata vengono classificate in modo diverso rispetto alle query a esecuzione prolungata.

Configurare

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

Al momento, la proprietà SchedulingBehavior può essere impostata solo tramite XMLA. In SQL Server Management Studio il frammento XMLA seguente imposta la proprietà SchedulingBehavior su 1, distorsione di 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>

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, ma possono essere modificate se necessario. Le proprietà seguenti non hanno alcun effetto a meno che l'interleaving delle query non sia abilitato impostando la proprietà SchedulingBehavior.

ReservedComputeForFastQueries : imposta il numero di core logici riservati per le query veloci . Tutte le query vengono considerate veloci fino a quando non decadono perché hanno usato una certa quantità di CPU. ReservedComputeForFastQueries è un numero 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 in un server con 20 core tenta di riservare 16 core per le query veloci (mentre non vengono eseguite operazioni di aggiornamento). ReservedComputeForFastQueries arrotonda fino al numero intero più vicino di core. È consigliabile non impostare questo valore di proprietà a un valore inferiore a 50. Ciò è dovuto al fatto che le query veloci potrebbero essere svantaggiate, il che è in contrasto con la progettazione complessiva della funzionalità.

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

ReservedComputeForProcessing : imposta il numero di core logici riservati per ogni operazione di elaborazione (aggiornamento dati). Il valore della proprietà è un numero 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. Il valore 0 (zero) indica che le operazioni di elaborazione sono soggette alla stessa logica di intercalazione delle query, quindi possono essere soggette a decadenza.

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 le 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 per le query veloci o le operazioni di elaborazione) verranno comunque usati per query veloci ed elaborazioni in caso di inattività.

Queste proprietà aggiuntive si trovano nel nodo delle 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 decadute

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 decadito o meno.

Ogni query può richiedere molti processi del motore di archiviazione. Quando un core nel pool di core per le query scadute diventa disponibile, lo scheduler verificherà la query in esecuzione più vecchia in base al tempo del calendario trascorso per verificare se ha già utilizzato il suo massimo entitlement core (MCE). In caso contrario, viene eseguita l'attività successiva. In caso affermativo, viene valutata la query meno recente. La query MCE è determinata dal numero di intervalli di decadimento già usati. Per ogni intervallo di decadimento usato, mce viene ridotto in base all'algoritmo illustrato nella tabella seguente. Questo processo continua fino a quando la query si completa, si verifica un timeout o l'MCE 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 rimanenti 12 core vengono allocati per le query obsolete.

DecayIntervalCPUTime è 60.000 (1 minuto di tempo cpu).

Il ciclo di vita di una query può essere il seguente, purché non vada in timeout o non si completi:

Se il sistema è sotto pressione della CPU, a ogni query non verranno assegnati più core rispetto al proprio MCE. Se tutti i core sono attualmente usati dalle query all'interno dei rispettivi MCEs, le altre query attendono fino a quando non diventano disponibili i core. Man mano che i core diventano disponibili, viene prelevata la query avente diritto più vecchia in base al tempo di calendario trascorso. L'MCE è un limite sotto pressione; non garantisce il numero di core in qualsiasi momento.

Vedere anche

Proprietà del server in Analysis Services