Soglie di ottimizzazione – Raggruppamento e aggregazione dei dati, parte 4

Qui, il costo del piano seriale [forzato] è maggiore o uguale alla soglia di costo per il parallelismo e il costo del piano parallelo è inferiore al costo del piano seriale, quindi SQL Server ha scelto il piano parallelo per impostazione predefinita.

Considera le seguenti query (le chiameremo Query 10 e Query 11):

-- Query 10: Serial
 
SELECT *
FROM dbo.Orders
WHERE orderid >= 100000;
 
-- Query 11: Forced parallel
 
SELECT *
FROM dbo.Orders
WHERE orderid >= 100000
OPTION(USE HINT('ENABLE_PARALLEL_PLAN_PREFERENCE'));

I piani per queste query sono mostrati nella Figura 5.

Figura 5:costo seriale>=soglia di costo per parallelismo, costo parallelo>=costo seriale

In questo caso, il costo del piano seriale è maggiore o uguale alla soglia di costo per il parallelismo; tuttavia, il costo del piano seriale è inferiore al costo del piano parallelo [forzato], quindi SQL Server ha scelto il piano seriale per impostazione predefinita.

C'è un'altra cosa che devi sapere sul tentativo di massimizzare il parallelismo con il suggerimento ENABLE_PARALLEL_PLAN_PREFERENCE. Affinché SQL Server possa persino utilizzare un piano parallelo, è necessario che sia presente un abilitatore di parallelismo come un predicato residuo, un ordinamento, un aggregato e così via. Un piano che applica solo una scansione dell'indice o una ricerca dell'indice senza un predicato residuo e senza alcun altro abilitatore di parallelismo verrà elaborato con un piano seriale. Considera le seguenti query come esempio (le chiameremo Query 12 e Query 13):

-- Query 12
 
SELECT *
FROM dbo.Orders
OPTION(USE HINT('ENABLE_PARALLEL_PLAN_PREFERENCE'));
 
-- Query 13
 
SELECT *
FROM dbo.Orders
WHERE orderid >= 100000
OPTION(USE HINT('ENABLE_PARALLEL_PLAN_PREFERENCE'));

I piani per queste query sono mostrati nella Figura 6.

Figura 6:Parallelism enabler

La query 12 ottiene un piano seriale nonostante il suggerimento poiché non esiste un abilitatore di parallelismo. La query 13 ottiene un piano parallelo poiché è coinvolto un predicato residuo.

Calcolo e test DOP per la determinazione dei costi

Microsoft ha dovuto calibrare le formule di determinazione dei costi nel tentativo di avere un costo del piano parallelo inferiore rispetto al costo del piano seriale che riflettesse un tempo di esecuzione inferiore e viceversa. Un'idea potenziale era quella di prendere il costo della CPU dell'operatore seriale e dividerlo semplicemente per il numero di CPU logiche nella macchina per produrre il costo della CPU dell'operatore parallelo. Il numero logico di CPU nella macchina è il fattore principale che determina il grado di parallelismo della query, o DOP in breve (il numero di thread che possono essere utilizzati in una zona parallela nel piano). Il pensiero semplicistico qui è che se un operatore richiede T unità di tempo per il completamento quando si utilizza un thread e il grado di parallelismo della query è D, ci vorrebbe del tempo T/D dell'operatore per il completamento quando si utilizzano D thread. In pratica, le cose non sono così semplici. Ad esempio, di solito hai più query in esecuzione contemporaneamente e non solo una, nel qual caso una singola query non otterrà tutte le risorse della CPU della macchina. Quindi, Microsoft ha avuto l'idea di un grado di parallelismo per i costi (DOP per i costi, in breve). Questa misura è in genere inferiore al numero di CPU logiche nella macchina ed è il fattore per cui viene diviso il costo della CPU dell'operatore seriale per calcolare il costo della CPU dell'operatore parallelo.

Normalmente, il DOP per la determinazione dei costi viene calcolato come il numero di CPU logiche diviso per 2, utilizzando la divisione intera. Ci sono eccezioni, però. Quando il numero di CPU è 2 o 3, DOP per la determinazione dei costi è impostato su 2. Con 4 o più CPU, DOP per la determinazione dei costi è impostato su #CPUs / 2, ancora, usando la divisione intera. Questo è fino a un certo massimo, che dipende dalla quantità di memoria disponibile per la macchina. In una macchina con un massimo di 4.096 MB di memoria il DOP massimo per la determinazione dei costi è 8; con più di 4.096 MB, il DOP massimo per i costi è 32.

Per testare questa logica, sai già come emulare un numero desiderato di CPU logiche utilizzando DBCC OPTIMIZER_WHATIF, con l'opzione CPU, in questo modo:

DBCC OPTIMIZER_WHATIF(CPUs, 8);

Utilizzando lo stesso comando con l'opzione MemoryMBs, puoi emulare la quantità di memoria desiderata in MB, in questo modo:

DBCC OPTIMIZER_WHATIF(MemoryMBs, 16384);

Utilizzare il codice seguente per verificare lo stato esistente delle opzioni emulate:

DBCC TRACEON(3604);
 
DBCC OPTIMIZER_WHATIF(Status);
 
DBCC TRACEOFF(3604);

Utilizzare il codice seguente per reimpostare tutte le opzioni:

DBCC OPTIMIZER_WHATIF(ResetAll);

Ecco una query T-SQL che puoi utilizzare per calcolare DOP per i costi in base al numero di input di CPU logiche e alla quantità di memoria:

DECLARE @NumCPUs AS INT = 8, @MemoryMBs AS INT = 16384;
 
SELECT
  CASE
    WHEN @NumCPUs  = 1 THEN 1
    WHEN @NumCPUs <= 3 THEN 2
    WHEN @NumCPUs >= 4 THEN
      (SELECT MIN(n)
       FROM ( VALUES(@NumCPUs / 2), (MaxDOP4C ) ) AS D2(n))
  END AS DOP4C
FROM ( VALUES( CASE WHEN @MemoryMBs <= 4096 THEN 8 ELSE 32 END ) ) AS D1(MaxDOP4C);

Con i valori di input specificati, questa query restituisce 4.

La tabella 1 descrive in dettaglio il DOP per i costi che ottieni in base al numero logico di CPU e alla quantità di memoria nella tua macchina.

Tabella 1:DOP per i costi

Ad esempio, rivisitiamo Query 1 e Query 2 mostrate in precedenza:

-- Query 1: Forced serial
 
SELECT custid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 300001
GROUP BY custid
OPTION(MAXDOP 1);
 
-- Query 2: Naturally parallel
 
SELECT custid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 300001
GROUP BY custid;

I piani per queste query sono mostrati nella Figura 7.

Figura 7:DOP per costare

La query 1 forza un piano seriale, mentre la query 2 ottiene un piano parallelo nel mio ambiente (emulazione di 8 CPU logiche e 16.384 MB di memoria). Ciò significa che il DOP per la determinazione dei costi nel mio ambiente è 4. Come accennato, il costo della CPU di un operatore parallelo viene calcolato come il costo della CPU dell'operatore seriale diviso per la DOP per la determinazione dei costi. Puoi vedere che è proprio così nel nostro piano parallelo con gli operatori Index Seek e Hash Aggregate che vengono eseguiti in parallelo.

Per quanto riguarda i costi degli operatori di scambio, sono costituiti da un costo di avvio e da un costo costante per riga, che puoi facilmente decodificare.

Si noti che nella strategia di raggruppamento e aggregazione parallela semplice, che è quella utilizzata qui, le stime di cardinalità nei piani seriali e paralleli sono le stesse. Questo perché viene impiegato un solo operatore aggregato. In seguito vedrai che le cose sono diverse quando usi la strategia locale/globale.

Le seguenti query aiutano a illustrare l'effetto del numero di CPU logiche e del numero di righe coinvolte sul costo della query (10 query, con incrementi di 100.000 righe):

SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 900001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 800001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 700001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 600001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 500001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 400001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 300001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 200001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 100001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 000001
GROUP BY empid;

La figura 8 mostra i risultati.

Figura 8:costo della query rispetto a #CPU e #righe

La linea verde rappresenta i costi delle diverse query (con il diverso numero di righe) utilizzando un piano seriale. Le altre righe rappresentano i costi dei piani paralleli con diversi numeri di CPU logiche e i rispettivi DOP per la determinazione dei costi. La linea rossa rappresenta il punto in cui il costo della query seriale è 5, ovvero la soglia di costo predefinita per l'impostazione del parallelismo. A sinistra di questo punto (meno righe da raggruppare e aggregare), normalmente l'ottimizzatore non considererà un piano parallelo. Per poter ricercare i costi dei piani paralleli al di sotto della soglia dei costi per il parallelismo, puoi fare una delle due cose. Un'opzione consiste nell'usare l'hint per la query ENABLE_PARALLEL_PLAN_PREFERENCE, ma come promemoria, questa opzione massimizza il parallelismo invece di forzarlo semplicemente. Se questo non è l'effetto desiderato, puoi semplicemente disabilitare la soglia di costo per il parallelismo, in questo modo:

EXEC sp_configure 'show advanced options', 1;  
RECONFIGURE;
 
EXEC sp_configure 'cost threshold for parallelism', 0;  
 
EXEC sp_configure 'show advanced options', 0;  
RECONFIGURE;

Ovviamente, non è una mossa intelligente in un sistema produttivo, ma perfettamente utile per scopi di ricerca. Questo è ciò che ho fatto per produrre le informazioni per il grafico nella Figura 8.

A partire da 100.000 righe e aggiungendo 100.000 incrementi, tutti i grafici sembrano implicare che se la soglia di costo per il parallelismo non fosse un fattore, un piano parallelo sarebbe sempre stato preferito. Questo è effettivamente il caso delle nostre query e del numero di righe coinvolte. Tuttavia, prova un numero inferiore di righe, iniziando con 10.000 e aumentando di 10.000 incrementi utilizzando le cinque query seguenti (ancora una volta, mantieni la soglia di costo per il parallelismo disabilitata per ora):

SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 990001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 980001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 970001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 960001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 950001
GROUP BY empid;

La Figura 9 mostra i costi delle query con piani sia seriali che paralleli (emulazione di 4 CPU, DOP per il costo di 2).

Figura 9:Seriale / soglia del piano parallelo

Come puoi vedere, esiste una soglia di ottimizzazione fino alla quale si preferisce il piano seriale e al di sopra della quale si preferisce il piano parallelo. Come accennato, in un sistema normale in cui o si mantiene la soglia di costo per il parallelismo impostando il valore predefinito di 5, o superiore, la soglia effettiva è comunque superiore a quella di questo grafico.

In precedenza ho menzionato che quando SQL Server sceglie la strategia di parallelismo di raggruppamento e aggregazione semplice, le stime di cardinalità dei piani seriali e paralleli sono le stesse. La domanda è:in che modo SQL Server gestisce le stime di cardinalità per la strategia di parallelismo locale/globale.

Per capirlo, userò Query 3 e Query 4 dai nostri esempi precedenti:

-- Query 3: Local parallel global parallel
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 300001
GROUP BY empid;
 
-- Query 4: Local parallel global serial
 
SELECT shipperid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 300001
GROUP BY shipperid;

In un sistema con 8 CPU logiche e un DOP effettivo per un valore di costo di 4, ho ottenuto i piani mostrati nella Figura 10.

Figura 10:stima della cardinalità

La query 3 raggruppa gli ordini per empid. Alla fine sono previsti 500 gruppi di dipendenti distinti.

La query 4 raggruppa gli ordini per shipperid. Alla fine sono previsti 5 distinti gruppi di spedizionieri.

Curiosamente, sembra che la stima della cardinalità per il numero di gruppi prodotti dall'aggregato locale sia {numero di gruppi distinti attesi da ciascun thread} * {DOP for costing}. In pratica, ti rendi conto che il numero di solito sarà il doppio poiché ciò che conta è il DOP per l'esecuzione (ovvero, solo DOP), che si basa principalmente sul numero di CPU logiche. Questa parte è un po' complicata da emulare per scopi di ricerca poiché il comando DBCC OPTIMIZER_WHATIF con l'opzione CPU influisce sul calcolo del DOP per i costi, ma il DOP per l'esecuzione non sarà maggiore del numero effettivo di CPU logiche visualizzate dall'istanza di SQL Server. Questo numero si basa essenzialmente sul numero di utilità di pianificazione con cui SQL Server inizia. puoi controllare il numero di pianificatori SQL Server inizia con l'utilizzo del parametro di avvio -P{ #schedulers }, ma è uno strumento di ricerca un po' più aggressivo rispetto a un'opzione di sessione.

In ogni caso, senza emulare alcuna risorsa, la mia macchina di test ha 4 CPU logiche, risultando in DOP per il costo 2 e DOP per l'esecuzione 4. Nel mio ambiente, l'aggregato locale nel piano per Query 3 mostra una stima di 1.000 gruppi di risultati (500 x 2) e un effettivo di 2.000 (500 x 4). Allo stesso modo, l'aggregato locale nel piano per la query 4 mostra una stima di 10 gruppi di risultati (5 x 2) e un effettivo di 20 (5 x 4).

Al termine della sperimentazione, esegui il codice seguente per la pulizia:

-- Set cost threshold for parallelism to default
 
EXEC sp_configure 'show advanced options', 1;  
RECONFIGURE;
 
EXEC sp_configure 'cost threshold for parallelism', 5;  
 
EXEC sp_configure 'show advanced options', 0;  
RECONFIGURE;
GO
 
-- Reset OPTIMIZER_WHATIF options
 
DBCC OPTIMIZER_WHATIF(ResetAll);
 
-- Drop indexes
 
DROP INDEX idx_oid_i_sid ON dbo.Orders;
DROP INDEX idx_oid_i_eid ON dbo.Orders;
DROP INDEX idx_oid_i_cid ON dbo.Orders;

Conclusione

In questo articolo ho descritto una serie di strategie di parallelismo utilizzate da SQL Server per gestire il raggruppamento e l'aggregazione. Un concetto importante da comprendere nell'ottimizzazione delle query con piani paralleli è il grado di parallelismo (DOP) per la determinazione dei costi. Ho mostrato una serie di soglie di ottimizzazione, inclusa una soglia tra piani seriali e paralleli e l'impostazione della soglia di costo per il parallelismo. La maggior parte dei concetti che ho descritto qui non sono univoci per il raggruppamento e l'aggregazione, ma sono altrettanto applicabili per le considerazioni sul piano parallelo in SQL Server in generale. Il mese prossimo continuerò la serie discutendo dell'ottimizzazione con la riscrittura delle query.